But Powershell builds on top of .NET, which means you can't write cmdlets in non-.NET languages. And writing them even in C# is quite painful. Which is why there is virtually no ecosystem for Powershell cmdlets and there is a gigantic, ever expanding, ecosystem of Unix shell tools.
At the end of the day you have to choose a primitive and history has shown that text is the right one.
PowerShell cmdlets can be written in PowerShell. PowerShell modules (the unit of distribution) can be written in entirely in PowerShell. You can also write them in a .NET language, like C#, F# or VB.NET.
I disagree that it is painful to write cmdlets in C#. A cmdlet is just a class, the parameters are just properties annotated with the [Parameter] attribute. The shell does all of the parameter parsing, matching and type conversion/coercion. If I wrote a traditional commandline tool I'd have to do that parsing myself. Yes, I could use a library function like getopt for that - but the code and complexity would still be there.
But my point was not to get anyone to use PowerShell on Unix/Linux. PowerShell draws much of it strength on Windows from the fact that there are already well-established object models on that platform (COM, .NET and WMI/CIM).
The point was that the age-old text-only view in command shells is beginning to show some shortcomings. XML and JSON (among other formats) challenge the tabular view of the world. Sometimes you have to experience the alternative to realize that you have been living in a restricted world. Like swallowing the red pill. Who know, maybe an object-oriented shell that mixes well with the Unix tradition will emerge.
PowerShell's "pipeline" is largely analogous to chained methods in a scripting language's REPL, and therefore is not the same as Unix pipes, which are used to share data streams between processes.
Unix already has the object functionality you see in PowerShell: Python, Ruby, the JVM, etc, and all of these have existed for far longer than PowerShell. The only thing PowerShell has is a bunch of shortcuts for system operations, which Unix already has in the form of POSIX shells and utilities, and which many languages provide language-native abstractions for.
At the end of the day you have to choose a primitive and history has shown that text is the right one.