I too am a Unix guy, but I came from a very Microsoft centric world: Microsoft itself. There, I used PowerShell day in and day out. It's a decent little shell. I much prefer it over cmd! That said, a better description for it would be a REPL. And if you think about it that way, then it's a pretty damn awful shell. It prefers to work with objects, so it tends to be frustrating to work with bytes. Besides, I've already got a great tool for working with objects: Python.
The bottom line is this: If you need a tool for operating on objects, then use a programming language; preferably choose one with a strong REPL. If you need to deal with persistent, serialized, streams of bytes, use a traditional shell.
I agree snprbob86, and that's what I was getting at. PowerShell doesn't know if it's a shell or an object-based language.
It's far too verbose. It's a shell, and a huge pain to type interactively. Yes, it has tab completion, but so does bash - and that's far less verbose.
It's also opaque. Because it's object-based, but you work with it on the command line, it outputs in text but there is constantly "other" information that is not displayed on screen that you can get if you pipe through to another command. That's not intuitive. Text processing is intuitive.
It reeks of design by committee. It's own execution policy. Java-like getter/setters. Super verbose syntax. About the only good thing PowerShell has done is force Microsoft to provide a command-line, scriptable interface to all their server products to get away from GUI dependency. And that's a product of their PowerShell internal policy, not the language itself.
Yes, it's better than CMD.exe. But still a huge pain. Other platforms have Python, Ruby, Perl... and dare I say it, bash.
Is it really all that verbose? The full cmdlet names like Get-ChildItem etc. are long, but there are standard abbreviations for most of them - which follow a more consistent naming pattern than short names in most languages/shells.
The bottom line is this: If you need a tool for operating on objects, then use a programming language; preferably choose one with a strong REPL. If you need to deal with persistent, serialized, streams of bytes, use a traditional shell.