Theme selection for mobile and tablets is still there on development site :/ Perhaps you have disabled device detection?
Some queries about how to implement an admin theme...
1. What exactly is 'backend' v 'front-end' - 'admin' v 'user' (admin potentially being Site Admin or Manager - or even a user with extended specific capabilities in some areas, user being tutor or student) in the context of how roles and capabilities are used within Moodle, or used as customised roles by institutions.
2. There are 'admin' settings present on pages that teachers may access as having editing rights. Do they all need to be separated out? or do you envisage the 'backend' theme incorporating all the editing screens as well, as it does in some/many/most other web scripts? Are you advocating that anything other than non-editing display (e.g. the 'student' view) becomes the 'backend' with this alternative theme?
3. How would the backend theme be applied - given that roles can be overridden and a student on one course may be a tutor on another and may have a particular capability that matches a site admin/manager role in another? OR would it be applied to specific pages (such as pages with admin or maintenance layout) regardless of who access them.
Bearing in mind that admin and maintenance layouts can already be targeted separately in a theme or that with the user themes setting enabled a site admin can already select a different theme, then perhaps the first step here is to actually create an 'admin theme' and then see how best to apply it or get it integrated to core?
Other functionality such as a common use of tabs/accordian/etc would need to be built into core - themes can already address it in their own settings (you've said you are working on tabs for BCU settings, I have implemented buttons for flexibase) but unless its part of core there is no commonality (see tabs/buttons - bcu/flexibase 
). With that in mind, what functions, other than themes, tend to have multiple settings pages that would require organisation through tabs (or buttons, or...)? Again, as a purely personal point of view, I prefer them in separate pages because I use the AwesomeBar and they appear in the drop down instead of a single page that I then have to use tabs for - but if tabs was the commonly adopted approach (separate pages have been upto this point) then that would be fine too.
Using the theme selector would certainly be another option for setting a different theme for certain purposes - all it would need would be someone to design the 'switch' to go with the device detection code to apply the relevant theme where it was required. That might depend though on your thoughts about the above points and whether an 'admin theme' is page specific or user specific.
For me, as I explained earlier, one of the crucial factors is that this 'admin theme' should not be mandatory as one earlier post suggested, but should be an option - hence I would prefer to stick to theme switching if and when I need it, (personal opinion) - I develop, act as site admin, provide multiple levels of support and teach. In all of those capacities I have a single look and feel, the editing and admin pages are integrated into my workflow and are not a separate entity. As well as Moodle, I use WP and Django in work, WP, Joomla and Drupal outside work. Of those, the separation of admin from front end is, as you say common, but ranges from ok to downright horrible to work with and that is with scripts that have been designed that way. For Moodle to switch to that from a system of integration would take a lot of thought and work to do it properly and not be left with another half-implemented solution that we seem to have so many of right now.
