The article is about exactly this. Powershell's job was not to be a decent shell, but to make server management work automatable. Unix style shells didn't solve this because windows was not file based, you need all these hooks into these various api to setup a user, or a network connection or a whatever.
Why it's .Net is also covered and its probably not what you expect.
The odd part is that, at its core, Windows still is file-based. Managing it isn't, but anyone who's gone digging around in NT's Object Manager will be familiar with using CreateFile() to get a handle for manipulating things there.
It's, in fact, pretty pervasive when interacting with Windows programmatically, just as it tends to be on Unix-alikes, and the fact that PowerShell doesn't do well to acknowledge that is frustrating. (Worse, Windows is a better Plan 9 of sorts with MIDL and COM everywhere, and PowerShell falls pretty flat here too compared to the experience of, say, slinging a dynamically generated command stream directly at fossilcons.)
Yes, I could break into C# or C++ for this, but that takes the tasks that rely on these operations firmly out of the hands of paraprogrammers.
Why it's .Net is also covered and its probably not what you expect.