PowerShell' object-oriented nature is great btw!
The canonical example of the complete failure and total friction is in the simple case of obtaining a file from a web server and sticking it on disk. This is the steps:
1. Try various built in cmdlets. Eventually find one that works.
2. It's a big file and gets entirely buffered in RAM and takes the machine out. You don't get the privilege of finding this out until you try dragging a 20GiB vhdx image from a build server to plonk on your SCVMM platform. That conks it completely.
3. So you think you'll be clever and just use curl. Oh no there's a curl alias!
4. Every damn machine gets sent a reconfig to remove this stupid alias.
5. Then when you do get there you find that the curl output pipe just pukes multibyte garbage out. 20GiB of it that took a long time to come across the wire.
6. You tell curl to save the file directly. Might as well have used cmd.exe by now!
So 8 Googlings and 3 hours later you got a fucking file. Every time I use powershell that is my life.
man iwr
man iwr -param outfile
Not to excuse bad examples on the internet (there are lots of people who fail to grasp PowerShell and still try to write articles and how-tos), but PowerShell having built-in documentation for commands and parameters is actually fairly easy to figure out from within the shell. Admittedly, once you learn the basic half dozen or so cmdlets you tend to use all the time.
You're free to ask me (or on SO, I tend to answer PowerShell questions there) if you're having trouble. Figuring above out took literally just 20 seconds. Really. I'm kinda sick of people cursing and blaming tools just because they're different from what they're used to. If I did the same and complained about bash and Unix (which I rarely find the need or time to learn) I'd be tarred and feathered in seconds ...
It's just that once you learn how to use a tool you don't have to think about how to approach a problem anymore, you just do it. And then, when learning a completely different tool you have to learn again. Surprise.
The problem with Powershell is that it tried to have its cake and eat it too - it wants the lightweight IDE of Unix-philosophy tools, but the detailed structure of C# objects. The problem is that the former is tightly tied to the simple common api of raw text, and the latter is inherently dependent on an intellisense-oriented IDE and static typing that heavily hints the names and parameters of useful actions.
Powershell manages to combine the worst of both worlds - objects means more complex APIs, but without the powerful IDE guiding you around those APIs.
It's also been really neat to see how well Powershell lends itself to extending other applications.
It actually is really good, but I do find it interesting that the first and last loser of the desktop wars got there a good long time ago.
[1] https://en.wikipedia.org/wiki/Workplace_Shell , https://en.wikipedia.org/wiki/Object_REXX