To me, the aesthetic of *nixes is the way everything is neatly arranged around the same set of relatively simple abstractions: executables, shell scripts, processes and text files. Yes, there's a learning curve, but once you're around the bend it's pretty flat. Skills are generally general -- once you know how to do X, chances are you've touched a great deal of the tools you need to Y.
Windows is somewhat simple (but unreliable) on the outside, and completely inaccessible on the inside. If you want to interact with the innards of Windows, there's somethings you can do in the registry, some things you need Scripting Host for, some things can be done in .NET, others you need COM for. Documentation for these things are spotty (you might find a guide for doing something in COM, in C++, and need to pair that with another guide on how to do COM in .NET). The learning curve maybe isn't as steep, but it keeps its inclination all the way to the wall you're bound to hit. There's little generality in skills -- once you know how to do X, you're still almost all the way back to square one on how to do Y.
It's true that core Unix has a degree of conceptual integrity that Microsoft software for example usually lacks†, but I wonder how much that buys you when put in the context of a complete system, running, say, Linux, GNU utilities (whose aesthetic tends to be subtly different), Emacs, X, GNOME, Firefox, OpenOffice, and probably some distro-specific system utilities/duct tape written in Perl or Python or something. I'm not sure the conceptual divergence can be written off as a fault of the divergent software, either.
† Microsoft tends to be fairly zealous about preserving backward compatibility while at the same time being aggressive about pursuing new trends. It's very difficult to do both of those and maintain conceptual integrity at the same time.
The same can be said for *nixes, in order to create something in sh using programs you need literally days of reading man pages for switches, etc or use perl, python, etc.. but even then many tools don't have bindings so you're back to use sh.
All operating systems currently popular are crap except for the most popular one in it's usage domain.
This assumes you aren't online, where nearly any shell script example you can think of is likely only a google search away. I don't think that anyone really spends days studying man pages anymore. Though it's nice that they are there when you need to look up something system-specific.
That's like saying language y is fine because I can just search and copy and paste... no you cannot. If you do anything beyond a simple [[ -f somefile ]] && do something sh turns into a nightmare.. case in point autotools.
Windows is somewhat simple (but unreliable) on the outside, and completely inaccessible on the inside. If you want to interact with the innards of Windows, there's somethings you can do in the registry, some things you need Scripting Host for, some things can be done in .NET, others you need COM for. Documentation for these things are spotty (you might find a guide for doing something in COM, in C++, and need to pair that with another guide on how to do COM in .NET). The learning curve maybe isn't as steep, but it keeps its inclination all the way to the wall you're bound to hit. There's little generality in skills -- once you know how to do X, you're still almost all the way back to square one on how to do Y.