> sadly you have to drop away from the pipelines to fuse operations to get decent performance
I used PowerShell as an example because it's currently an important part of the Windows ecosystem and works very well with piping. In my experience using PowerShell (on Linux) as my daily driver I haven't noticed performance losses in using pipelines. That being said, maybe I'm losing more resources by not optimizing every command I run, but so far I am pretty happy using PowerShell while heavily using pipelines.
The good thing is that in dynamic languages (VBScript, Python, PowerShell) you can instantiate COM objects and call their methods in a couple of lines. I have never held the "oh but COM is badly designed and complicated inside" complaint in high regard, because the alternatives are either: it should be easy for programmers and if it's hard for users who cares, which is worse, or if it's not easy for programmers it shouldn't exist at all, which is also worse.
Windows had system-wide IPC (OLE and COM/DCOM) since Windows 95 that Linux doesn't have today, and which I suspect Linux users don't even know they're missing. You want a spreadsheet in a word document, you could drag it in there and Excel as a component would appear inside Word. You want to extract JPG metadata in your VBScript, call WScript.Shell and lean on Explorer to do it. Array calculations? Automate the 3rd party J engine. Voice recognition in Python with PyWin32? Instantiate SAPI.SPVoice. System wide task/specialty-focused components not like installing a node.js library, but available to any language or any program which speaks the same interfaces.
It isn't /piping/ but it isn't everything-reimplements-the-world either.
> "An example that also highlights this is Microsoft's work on PowerShell -- which is built to be used in complex pipelines"
And sadly you have to drop away from the pipelines to fuse operations together to get decent performance.
will not be as fast as because the first one has to generate pipeline data for every file only to filter most of them out, the second one can generate only the data which is needed in the first place. And this problem of fusing operations to avoid wasting resources is endemic to pipelines, not only to PowerShell - see Unix shells serialising everything to text at the output of a command only to parse it from text at the input to the next command, or how commands gain ever more options to do with filtering and processing, summarising and formatting, which aren't anything to do with the "one thing" they allegedly do.