I've been using AQT for nearly a decade, although not so much recently since my machine is pure Ubuntu; AQT does run under wine, but the rendering has some quirks.  But, for those in the WinWorld, it is a superb talks-to-any-ODBC database tool, and not very expensive.  It has the advantage of presenting a consistent interface to such a realm of engines, even DB2/mainframe of all things.

Given the fantastic tools that have been developed by RedGate - why doesn't RedGate have or consider a tool in this space?

SQLPrompt and SQLRefactor could also then be add-ons to this.

Seeing as how MS wants to push the CLI for admins with Powershell, I think that a SQL variant of Powershell may be what is needed.  The Powershell extensions SQLPSX and POWERGui are tools which are bridging this gap.  I must admit that I have skirted around Powershell far too long.  After reading what some people have done with it and SQL Server (reporting/system monitoring) I really need to get stuck into it.

The major difficulty in itself is getting the people from the "other side" to even acknowledge that SQL Server *really* is a system that can contend with Oracle.  I think that it is similar to the O/S discussion/war.  If tools like Powershell are there to get the CLI-Junkies to accept/work with a tool, then all the better.

I hope that MS takes heed of these sort of discussions, as it can only help them steer the product to match the market needs.  A complete CLI implemetation of SSMS is overboard, but a firm extension of Powershell should be firmly within their reach.

I used to work with TOAD.  While the layout is somewhat different, the basic functionality in TOAD was similar enough to the SSMS predecessor that I was able to make the leap to SQL Server 2000's interface easily enough.  

Likewise Teradata has a GUI interface and another text editor.  
I suppose die-hards could make a case for a stripped down editor, but in my Teradata days, I found that I was frequently using both in order to for example, more easily scan objects 'graphically'; in short, I used the GUI as a reference to find out about the objects I was writing for in the script editor.

So, IMHO only, the issue is not "to GUI or not to GUI", the issue is - how could MSFT make SSMS more efficient and faster; and why don't they?
1 - new query window.  So there's a button?  Big deal.  You have to use File/New to figure out the quick keys - at least on my SS 2008 interface, hovering over the new query button doesn't tell me the quick key for a new query.  That said, there is only a quick key for a new query on the current connection.  
2 - shortcut keys for hopping amongst connections.  I have at present 4 production instances and a plethora of development and testing connections.  Sure I can have multiple connections open, but I've yet to find a simple method of jumping between them - one may exist, but it is not straightforward enough.
3 - Keeping connections - supposed I have 2 'favorite' or 'every day' production servers that I query.  Why oh why can't I set them for a default login so that when SSMS starts up I don't have to constantly thread through the server list and make a connection to each one - those of you who use SQL Backup will understand what I want.  Just a way to set connection lists so that when SSMS starts up it logs directly into these servers.
SSMS should extend this abillity also to the other types of logins (SSAS, SSIS, etc.)
4 - GUI needs some improvement !!  It takes toooooooooooo looooooooonnnnnnggg to enumerate a tree if there are a large number of objects; morever, if the object is busy (like a database nearing a saturation) you get the equivalent of deadlocks or blocks - longer wait times or even nothing at all.  
Howabout being able to apply the filter BEFORE enumerating?  If I know that out of say, 1,000 tables I only want to see tables starting with 'inv_', of what benefit it is to me to enumerate the whole table tree so that I can then apply the filter?  If the tree has been enumerated and displayed by the time I can open the filter box and fill it in, I could just have easily page down'd the table list to tables starting with 'inv_'
There are a lot of things about the 'left-hand' pane of SSMS that just scream 'FIX ME, MAKE ME FASTER!'

These are just the few 'off the top of my head' things I wish I could do with SSMS.

That said, would I really prefer to use a stripped down scripting editor?  Is it really gaining me that much vs. opening SSMS and taking a second or two to get 'new query'?

I just don't see the need.

How would you compare and contrast SQL*Plus with sqlcmd (from an erstwhile or seldom user of each)?

With all due modesty, I think I have a solution. Read this http://www.simple-talk.com/community/blogs/philfactor/archive/2008/10/14/69990.aspx 'Cold Turkey with SSMS'. You can have both. You use SSMS for all those things you love, and use your favorite  Programmers' Text Editor for developing code fast. SQLCMD does all the hard work, but you never let it show its face. Oh no, SQLCMD is far better kept as your highway to the database rather than as a user-interface.
My view is you need both SSMS and a programmers text editor. The one without the other makes development much slower.

I worked in Oracle for nearly 20 years on OS2, many versions of UNIX and Windows.  I used TOAD, and in fact continue to use TOAD to manage some aspects of SQL Server (Microsoft, note that it would behoove you to look at Toad 4.6!) In that midst, I began working with Sybase and the company switched to SQL Server.  The front end for 4.2 was ludicrous, but in 6.5 the tool was called SQL Enterprise Manager.  It made my Oracle DBAs envious.  Almost all the things I could do in TSQL could be done from the GUI. Then came an attrocious front end called SSMS in SQL 2000, but the buyin was a great little tool called DTS.

In 2005, SSMS became a little better for a GUI DBA front end, but they let developers buid a product like SSIS to replace DTS and the DBA's had to become pseudo-developers. "Not that there's anything wrong with that."  It's just the DTS front end was more direct and straightforward.  SSIS is more adaptable.  

With all that said, first, I still think the GUI front end for SQL Server is better than that of Oracles, but it should be. It only runs on Windows and for that matter, it should even be MUCH better, than it is.  Next and last, I don't live and die in the GUI, I still use SQL to perform many tasks as well as Powershell scripts.

There used to be such a tool in SQLServer 7.0 and 2000 called Query Analyzer but Microsoft in all their wisdom decided to replace it with SSMS !!

I thought it was a great tool that could be used by developers without giving them access to Enterprise Manager with all its DBA-type functionality for them to explore.

When QA was removed in SQLServer 2005 I was somewhat dissapointed. I have received comments from Oracle developers / DBAs that the initial learning curve when first working with SSMS was quite steep and thet they could get lost in all the functionality.

A tool like QA was ideal for those crossing over from Oracle to SQLServer and I do miss it. Some will say it is progress but I thought a low footprint tool like QA definitely belongs in the armoury of DBAs and developers alike.

Personally, I have no desire for a SQL Server Version of SQL*Plus.  When I have had occassion to work with Oracle, I have in fact sought out tools like Oracle SQL Developer to bring working with Oracle closer to using SSMS.  Overall, I am quite impressed with SSMS, especially when coupled with some of the tools such as SQL Refactor.  

Of course, different people have different tastes, and I can understand a desire for more options and particularly for an option that loads faster than SSMS.  But for those people, Phil Factor did provide alternatives in the article he lists in his comments through use of SQLCMD.

GUI ?  PL/SQL ? SQLCMD ? SQLPSX and POWERGui ? TOAD ?

I like PL/SQL, SQLCMD and Enterprise Manager, but these tools doesn't provide me the depth of understanding in both the work of SQL and the structure of the database.  I rely on the people's thought from blogs and technical discussion forums for knowledge to increase my practical experience.

I would love to see a "Wonder Wheel" tool, see http://www.googlewonderwheel.com/

This Wonder Wheel concept can be used in both the SQL management and the database management.  I am sure this will give us enormous information of how these work.

CIAO!

I have used Oracle's version of SSMS and the Oracle Equivalent is slow... slow to start, slow to do anything. SSMS does have a learning curve and I did miss the simplicity of Query Analyser, but now I think SSMS is excellent.

(I found SQL*Plus to have an significant learning curve but once learned was an excellent tool)

Hmmm.  If the topic is how to "lure" more Oracle DBAs into drinking the SQL Server Kool-Aid, I think the biggest obstacle is not technological but financial, at least the last time I checked:  Oracle DBAs tend to make more money than SQL Server DBAs, at least here in the States.  Admittedly, I haven't looked around in awhile, but when I was, it seemed that Oracle DBAs can easily earn 10 - 20% more than their SQL Server counterparts.  Why?  Well, I'd be guessing, but here's my best guess:  you don't have to sell Oracle's end-user base on the benefits of having a top-notch technical staff.  Part of SQL Server's problem is the way it has often been marketed (similar to other Microsoft products) as the database for database illiterates.  The (relatively) easy-to-use GUI has lulled non-technical folks into thinking, gee, DBA work isn't all that hard after all.  Consequently, in the minds of non-technical corporate bean-counters, SQL Server gets shoved into the slums of Excel, Access, and other apps that promise instant data gratification on the cheap.  It takes a datatastrophe to convince them otherwise.

(My second best guess is that Oracle is well-established in the defense contracting racket, and military and other government contractors tend to make more than those of us who deal with more penurious, less profligate employers.  I'm not saying they don't earn the extra money, mind you; contracting for the U.S. government is a maddening set of headaches and heartbreaks all its own.)

As for the tools, SSMS is too useful to be considered wretched, but I worked in Oracle a number of years back and thought TOAD was much better.  (So whatever disincentives there are for Oracle DBAs to switch sides, they weren't quite enough to keep me from crossing over nine years ago.)  To me, the biggest sacrifice in become a SQL Server DBA is not the difference between Oracle and SQL Server, but between Unix and Windows.  I actually kinda like SQL Server, but I will never like Windows.  Powershell has come out recently to the sound of orchestrated clapping from the Microsoft claque, but Korn, Bourne, and C-Shell has been available in Unix systems for, like, forever, and they are far easier to learn.  I often grow wistful for the days when programming was an exercise in logic rather than a frustrating right-clicking, curse-filled Easter egg hunt through menus, properties, and inscrutable documentation to find the precise procedure -- excuse me, method -- to do what I need.

It's interesting that TOAD is a third-party tool, while SSMS is bundled in by the vendor.  Perhaps this reflects the business plans of the respective companies.  Oracle has made far too much money selling consulting services to waste time making their DBMS easy to use -- sort of a built-in disincentive.  On the other hand, Microsoft's main line of business is selling "easy-to-use" operating systems -- and so SSMS comes with SQL Server to promote, subtly, that which, to a DBA, is the most noxious of notions: that our employers can get along without us.

I am an Oracle-SQL Server hybrid DBA though I work only with SQL Server currently.  I can do all the command-line scripting I need with a good text editor, PowerShell and SQLCMD.  What's the issue?