I realize this post is not fully baked. I've got some obvious flaws in my reasoning. But my boys are home and I want to play with them, so I'm done thinking about this for now.

If only there was a place where people would come and, for absolutely free, point out every flaw in your reasoning.

Oh, wait - I know a place like that! Good. Here you go, you million-monkey-strong critics - tell me what I'm missing!

Microsoft is getting closer in parts of Windows 7.
But there are other parts of Windows that are hopelessly crufty in both underlying tech and in UX. Often times I suspect the crap UX is built right into the functional code, and fixing the former would require completely rewriting the latter because they're co-mingled code.
(I haven't examined the source, I could be totally full of crap. But fer cryin' out loud look at the name of this blog. Do you think I take myself all that seriously?)
Now Microsoft has been, for several years, realizing that they have to fix the architecture of their code in order to deal with their UX.
Simon Guest has been big in this.
But I also think of the UW CSE Colloquia talk I saw a few years back, where an analysis of Windows' codebase was done, and the resulting spaghetti pile of circular dependencies was finally seen for what it was: hopeless. This led to a renewed effort at making Windows more modular, which ended up headinng towards MinWin and Server Core.
The Exchange team deserves big credit here; Exchange 2007 was really much more cleanly modular with its implementation of server roles. But Exchange didn't just go modular; they also went with PowerShell - AFAIK, they were the first major production use for PowerShell, and they really proved the case in the real world by making life easier on Exchange admins and providing a more powerful set of tools - and enabling people to make their own tooling much better & more easily. (Yes, yes, I KNOW *nix admins have that that for ages. Quiet. That's not the point here.)
So the importance of PowerShell is that if you architect the code so it's cleanly modular, with a regular API for other parts of the system to interact with it, you can ALSO have the UX layer with flexibility to change - and either iteratively evolve towards improvements, or even try something completely different, WITHOUT FEAR of breaking the whole thing.
Having the capability doesn't mean success is inevitable. But it sure means success is more possible than it was before the capability was there.