It's FAR TOO HARD to pass parameters to applications which require quoted strings. I asked this question in IRC with a "roomful" of PowerShell experts, and it took hour for someone to figure out a way (I originally started to post here that it is simply not possible).
This completely breaks PowerShell's ability to serve as a general purpose shell, because we can't do simple things like executing sqlcmd. The number one job of a command shell should be running command-line applications...
As an example, trying to use SqlCmd from SQL Server 2008, there is a -v parameter which takes a series of name:value parameters. If the value has spaces in it, you must quote it. For instance, this will work in cmd.exe (it doesn't do anything, just exits silently):
sqlcmd -v user="Joel Bennett" -Q "select '$(user)' as UserName"
But in PowerShell, it has to be:
sqlcmd -v user=`"Joel Bennett`" -Q 'select ''$(user)'' as UserName'
Notice that you have to escape things two different ways here? How many people are going to figure that out?
But it gets worse if you need to user a variable (eg, $Env:FullName):
So you can execute it in CMD:
sqlcmd -v user="%FullName%" -Q "select '$(user)' as UserName"
But how many PowerShell users are going to figure out that this (sortof) works:
sqlcmd -v user=($env:FullName) -Q 'select ''$(user)'' as UserName'
What appears to be happening is that "user=($env:FullName)" is treated as a two part array: "user=" and "Joel Bennett" ... so the engine inserts a space after the "user=" (which I can't get rid of by setting $ofs, oddly) and then inexplicably and magically chooses to wrap quotes around the "Joel Bennett" ....
The problem is, as you can see from these examples, there is no single way to write a command line to invoke this application correctly, so even after you master all 4 or 5 different ways of quoting and escaping things, you're still guessing as to which will work when ... or, you can just shell out to cmd, and be done with it.