Don Jones sums up the detractors' position pretty well:
But they have created a SQL Server-specific version of Windows PowerShell, which is what you use if you want to use SQL Server 2008 cmdlets or the new provider. And this new console is closed - you cannot add more functionality to it by using Add-PSSnapin.To say that this is “stupid” would be unkind to all the stupid people out there. This “closed console” is stupid on a level heretofore unknown. The SQL team is basically taking a great, all-purpose administrative tool and locking it down. They’re returning us to the good old days of Windows NT, when everything was administered by its own, separate, non-integrated admin tool. THIS SUCKS.
Well it's all Jeffrey Snover's fault (see his full post here), but he's got some solid reasoning behind his decisions:
During the Vista reset, there was a great deal of anxiety about .NET versioning and general angst about instability arising from plugin models where code coming from the various sources run in the same process. Imagine the case where you load plugins from 10 different sources and then something goes wrong - who is responsible?...The problem is not that SQL shipped a MiniShell but rather that there are SQL UX scenarios that use the MiniShell instead of a general purpose PowerShell. The SQL Management Studio GUI has context menus which launch their MiniShell. This is where we made a mistake. By definition, this is an escape out to an environment to explore and/or perform ad hoc operations. This environment does not benefit from the tight production promises that a MiniShell provides, in fact it is hampered by them.
He goes on to say that the issue will be rectified in a future release (SQL Server 2008 is only a Community Technology Preview now).
This brings up interesting possibilities, though. I wonder how easy/hard it is to create a MiniShell.