As Joe mentioned, you are complately free to organise your css files as you see fit by defining them in the style.config file they will be combined and minified so its possible to organize in multiple files as I did or you could put it all in one and you can put common ones in a shared location. The only reason all the included skins are done the same way is because I made them and I tend to do them the same way. A Few years ago I read a CSS book where the author mentioned it was a useful strategy to break things up by functionality like colors in one file borders in one file, background images in one file, then you could easily change just the colors by swapping out a different color file or change borders etc. I admit that over time as I have added new things to the css I tend to just add stuff to the bottom of the stylelayout.css because its less work than editing multiple files especially when I'm needing to add some css to all the skins I include. Different designers have different preferences about how to organize them so we support that by our style.config file and css combiner/minifier.
Its true you don't have control over css class names but enough classes are used in the markup to allow any kind of selectors for any kind of styling. The markup is structured with good semantic headings and structure but it does have extra non semantic divs primarily to make it easy to skin.
Its true that you don't have control over the markup of features but you do have control over some markup in the layout.master and you also have control over all the markup in your content like within an html module or within a blog post. Please understand to make it possible to skin a site with CSS there have to be consistent markup otherwise how can I make css based skins to style it. I've looked at ways of trying to make templates for different features but it would be complicated and would result in an explosion of files because the templates would have to exist in each skin to meet my goal that skins are self contained and can be changed with one click. Also upgrades would be problematic because templates would have to have some code in them so if my code changes and someone has a skin with an old template it becomes a problem.
I do have some future plans for some extensibility points that will allow you to inject some extra markup in various places like the side bar of the blog for example.
There are some differences with working with a pre-compiled language vs an interpeted scripting language like PHP. They have easy mechanisms for include files for both markup and script and if you are used to that it can seem like you are losing some control things you had more control over in that environment. But really our markup is pretty good and limitations mainly come from lack of CSS knowledge. Those who are really good with CSS don't have much trouble skinning mojoPortal at all.
So, in short its not easy to provide something that both provides consistent markup and a set of skins that work and also give you complete control over markup. If there were an easy way to do it I would but all ways I see are complex. its a little better in the new ASP.NET MVC model where you can override views it becomes easier but its still problematic because there is code in the views and a custom view could easily break when a feature is changed or upgraded. And its gigantic task to move to the MVC framework from WebForms. Over the long haul I plan to begin a separate project for and MVC UI on top of the same plumbing as our WebForms version but it will be a long time before it has anywhere near the functionality we have now in WebForms. Any CMS is going to take away some control over markup, the only palce where you have complete control is static html, there is always a tradeoff.