PowerShell unfortunately just isn't that first-class, even on Windows. You'll inevitably discover, if you do this, that certain things simply can't be automated via PowerShell, that some PowerShell modules wrap or lag behind older Windows CLI tools, that various things you want to do still require manual registry hacks, etc.
Try starting from a blank slate Windows machine and making a commitment to only changing settings via PowerShell, and ideally only declaring them using DSC. You'll soon discover settings where the best you can do is snapshot the registry, change a setting in the GUI, snapshot the registry again, then take a diff so you can write the registry change into your PowerShell automation. If you're on a corporate machine, you'll also likely find many corners of PowerShell that you need closed off to you, anyway.
At the end of the day, Windows is not friendly to automation because it's not CLI-first (not culturally and not technically).
Your argument is directed at Windows, not PowerShell. The shell is just a shell, if a certain thing you're looking to configure doesn't have an easy cmdlet, that doesn't mean powershell is bad, just that MS didn't give you the easy button. Similar to many unix tools, some of what you need to interact with has a dedicated CLI, other things have you poking at the configuration database directly (ini or yaml or whatever for unix, registry for windows).
If you don't like the Windows style of configuration, run powershell on linux - it's awesome there too!
I'm not sure why reading and writing the registry is considered a bad interface for programmatic system administration.
I realize text files can be processed by utilities for working with text files. And text files can be read by humans without any tools, and in that sense are rather universal.
I wonder what I'm missing.
I'd go so far as to think an OS that had a database at its core, or perhaps a persistent lisp would be even more programmable and legible.
Maybe better tools for dealing with structured data would help this?
Try starting from a blank slate Windows machine and making a commitment to only changing settings via PowerShell, and ideally only declaring them using DSC. You'll soon discover settings where the best you can do is snapshot the registry, change a setting in the GUI, snapshot the registry again, then take a diff so you can write the registry change into your PowerShell automation. If you're on a corporate machine, you'll also likely find many corners of PowerShell that you need closed off to you, anyway.
At the end of the day, Windows is not friendly to automation because it's not CLI-first (not culturally and not technically).