Please don't remove all the non-CSS-heavy skins! At least leave one "linear" one (probably Chick). Many people on low-bandwidth connections prefer these, and such folks probably wouldn't mind if things like AFT and WikiLove didn't work on them. And the accessibility benefits cannot be forgotten. The skin could be renamed "Minimal" or "Low Bandwidth" or "Classic" or "Accessibilitas" or something similar.
Topic on Talk:New skins system
The claims about Simple, Chick, etc... being low bandwidth are complete FUD. Vector loads ~19.3KB of CSS while Simple loads ~11.9KB this is only around half the size, for all that loss of UI this isn't a significant enough bandwidth gain. Especially when you factor two things in. We load ~134.7KB of JS, this applies to every skin, including Simple. This means that while you manage to save 10 measly KB you've barely made any savings at all since you still have x13 that being loaded. And the other thing, is we have nice and aggressive caching. So no matter what skin you're using after you've downloaded the assets once you don't download them again. So there is no point to trying to micro-optimize like this.
As for the user who are in fact on low bandwidth connections. They should be using the mobile site, not a full fledged desktop skin. That's what it's for, small screened and low bandwidth clients.
And these skins have no accessibility benefits. Accessibility is supposed to be always-on. Jump links, flexible font sizes, etc... accessibility is something in the background that should be done for every skin. Skins like simple and chick don't improve accessibility. Moreover basic accessibility should NEVER be a user preference. A person should never have to create an account and login just to get accessibility. Accessibility should be built into the site default skin. The thought of these skins providing an accessibility improvement to MediaWiki are also FUD.
So skins who's entire rationale for existing is based on FUD have no business being in core.
Some people actually like to edit Wikipedia on low-bandwidth connections, which is currently not possible on the mobile site, so they need to change skin.
I personally think a scriptless skin should be provided. While MediaWiki:common.js, etc, would still be loaded, all the cruft like floating menus, extensions, edit toolbar, etc should not be loaded, to save more bandwidth. (sorry, I am the OP at a different IP)
The mobile site will eventually have editing and that point will end up moot (bug 30306). In any case as I have already explained simple/chick are not low bandwidth they offer no significant bandwidth savings. And any small fraction of savings you gain is mooted by the browser caching. So Simple and Chick still don't have a proper rationale to stay.
As for scriptless, if you don't wan't scripts then disable JavaScript. If it's not enabled then the browser doesn't download it.
As for the idea that we should offer a skin that loads stuff like commons.js but not other things. I should first point out that what you are describing is not a skin. It has nothing to do with this. All of those things are general features loaded in all skins by mw, not by skins. So what you are describing would really be a user preference that would apply to any skin, it's not a reason to keep skins like simple or chick around. In any case your idea will likely not save as much bandwidth as you think it would.
Firstly sizes. The total loaded on an empty cache is 154.3KB (4.3KB is a banner so you might as well make that 150KB). Common.js is 3KB. However site scripts depend on jQuery and our mediawiki JS libraries to function. Those libraries are 45.4KB. In other words even just including the most basic of necessities we already eat up 1/3 of what we load in total.
Another 1/3 is eaten up by a 50.1KB script. This script includes some things like ext.Experiments, article feedback, collapsible elements, and charinsert that you may consider unnecessary. But it also contains mw-jump, the placeholder shim, tabIndex, our core mw.Title, mw.Uri, mw.api, and mw.user libraries that other things depend on, the mediawiki.page.ready which is also a necessity, and also our ajax watch code. All that stuff of course is a mix of necessities, things that necessities depend on, and things like ajax watch. And I won't let you say that ajax watch isn't useful. Because ajax watch replaces an entire whole page load likely over 10KB alone with no caching, with a tiny script that gets browser cached and not re-loaded plus a 390B (not KB, pithy little bytes) api call. That script actually saves you bandwidth.
Simple search and collapsible navigation. The latter probably falling under your selection unnecessary stuff is a mere 5.6KB. Reference tooltips are a mere 2.3KB.
And of course after all this, bandwidth concerns are mooted by the fact that after the page view that 150KB of JS isn't loaded again. It's all cached in the browser. The only JS that is re-loaded is a tiny 4.3KB banner. So trying to micro-optimize is still pointless.
Also I should mention that our long term goal should be to kill Common.js. Site scripts should eventually be compartmentalized into individual gadgets with proper dependency handling, etc... instead of all shoved into one page in the i18n system where it doesn't belong. So it becomes even harder to use the criteria of partial loading that you describe.
But just to finish up. Trying to save bandwidth by getting rid of css or js like this is pointless. It takes up hardly any bandwidth as we already optimize it and then it gets cached into your browser and you aren't loading it anymore. While on the content side, en.wp's homepage loads 111KB of image thumbnails. Visiting an article will likely land you on an article around ~100KB of HTML from all the text with an additional potential 500KB of thumbnails. In other words two simple page views of content you are actually aiming to see eat up more bandwidth than the all of the css and js you are trying to optimize away. That is how insignificant a savings you gain. And in return, you loose accessibility features, and piles of features that improve your experience on the website, whether you know that or simply take it for granted.
You may well take the righteous view, but a lot of people are going to disagree with you on Wikimedia wikis!
The bandwidth differences between the skins are negligible so my feeling is they are using Chick because it "looks cleaner" on tight spaced mobile devices than Vector. This could easily be fixed by making Vector's CSS more responsive, instead of maintaining support for legacy skins. I believe that the Athena project would address these concerns adequately. Athena hasn't been resourced by the WMF, but my gut says that all the mocks can be done with tweaks to Vector without creating an Athena skin, and I'd imagine the mobile team will be driving this effort sometime next year just out of the need to merge the mobile web code back into core.