Your overall post is very insightful, but the specific example of Windows is would have been always wrong and especially now is spectacularly outdated.

Windows for decades has had a concept of "object oriented" composability, first through simple message passing, and later through things like the Component Object Model (COM), DCOM, Object Linking and Embedding (OLE). Among other things, this allows quite high level composability, such as Excel graphs in Word documents. This includes system management APIs such as the Windows Management Instrumentation, which is inherently object oriented and has been available for over a decade through the VB or JS shells, and even CMD/Batch shells using "wmic.exe"

Now, UNIX people will argue that this isn't the same as the typical GNU toolset and a shell like bash. They would be right. In Windows, there's a gap between "I can drag and drop an Excel spreadsheet into Word" and "I can use C# to automate COM APIs". It's a big gap. I crossed it, I've seen commercial products that also do various forms of COM automation too, but I can count on one hand people that I have met "in the field" who have ever automated Windows in this manner.

In other words, this gap was wide enough that many people -- especially those most familiar with UNIX -- would often claim that there's nothing on the other side. But this just isn't true.

These days, everyone uses PowerShell, because it bridges that gap. It wraps all of those OO APIs that have existed for a long time in a unified platform. It can natively call WMI APIs, COM, WS-MAN, .NET, and has wrappers for the legacy DCE/RPC management APIs too.

If I can leave you with one takeaway sentence from this is, then it's this one: PowerShell is more UNIX than UNIX.

Seriously. In UNIX, if you want to sort the output of "ps"... sss... that's hard. Sure, it has some built-in sorting capabilities, but they're not a "sort" command, this is a random addon it has accumulated over time. It can order its output by some fields, but not others. It can't do complex sorts, such as "sort by A ascending, then by B descending". To do that, you'd have to resort to parsing its text output and feeding that into an external tool. Ugh.

Heaven help you if you want to sort the output of several different tools by matching parameters. Some may not have built-in sort capability. Some may. They might have different notions of collations or internationalisation.

In PowerShell, no command has built in sort, except for "Sort-Object". There are practically none that do built in grouping, except for "Group-Object". Formatting is external too, with "Format-Table", "Format-List", etc...

So in PowerShell, sorting processes by name is simply:

    ps | sort ProcessName

And never some one-character parameter like it is in UNIX, where every command has different characters for the same concept, depending on who wrote it, when, what order they added features, what conflicting letters they came across, etc...

UNIX commands are more an accident of history than a cohesive, coherent, composable design. PowerShell was designed. It was designed by one person, in one go, and it is beautiful.

The acid test I give UNIX people to see if they really understand how weak the classic bash tools they use is this:

Write me a script that takes a CSV file as an input, finds processes being executed by users given their account names and process names from the input file, and then terminates those processes. Export a report of what processes were terminated, with ISO format dates of when the processes were started and how much memory they used into a CSV sorted by memory usage.

Oh, there's a user called "bash", and some of the CSV input fields may contain multiple lines and the comma character. (correctly stored in a quoted string, of course!)

This kind of thing is trivial in PowerShell. See if you can implement this, correctly in bash, such that you never kill a process that isn't in the input list.

Give it a go.