See (for instance):
http://www.amnh.org/exhibitions/hall_tour/spectrum/non_flash_index.html
This isn't about an imposed classification, it is about a family tree. Crocodiles are more closely related to birds than either are to snakes. Snakes are more closely related to birds than either are to turtles.
That is, these guys:
http://www.wolaver.org/animals/crocodile-plover.jpg
share a *much* more recent common ancestor than these two:
http://berkeley.edu/news/media/releases/2009/02/images/salamander-pgoebeil.jpg
and:
http://images3.wikia.nocookie.net/__cb20090630160120/uncyclopedia/images/2/2f/Geico-gecko.jpg
You are more closely related to a goldfish than the goldfish is to a shark:
http://rlv.zcache.com/goldfish_bowl_tshirt-p23514656184174989535jn_400.jpg
Some of these comments are isomorphic to this review of Richard Dawkin's history of your family tree:
http://creation.com/review-the-ancestors-tale-richard-dawkins
It's naive to consider either class of software as being sufficient, or either kind of programming to be superior. Like most problems there is a strong management component to assigning resources to each in appropriate scales.
A computer scientist/software engineer delivered a well-phrased summation of half of this discussion during a 5-minute talk at a recent lightning software session at a science meeting. (Note that there are rarely science sessions at software meetings.) A domain scientist/software engineer then delivered a well-phrased summation of the other half of this discussion. Both were right and both were wrong.
My five minutes? Pointing out that the real issue was that management rarely supplies sufficient resources to coherently accomplish software projects of any type. Typically projects are underscoped by a factor of three or more, whether the particular project is to build a robot or an exoskeleton. This is true whatever software process is followed, but in terms of the Mythical Man Month, it's like omitting the nurses and anesthesiologist from the surgical team.
Somebody mentioned wanting a planetarium at home. This is very doable. The current version of WorldWide Telescope:
http://www.worldwidetelescope.org/
supports a very straightforward remapping onto a dome through multiple projectors (don't know about the military grade nonsense). There's a calibration screen that handles all the geometry. Just need some baffling to minimize the overlap between projectors.
Navigating through the Sloan galaxies is very impressive on a planetarium dome. WWT also displays a half million objects in the asteroid belt, Kuiper belt, etc in real-time (or in accelerated motion) using that space-age GPU technology. (Of course, "real-time" is another overused buzzword.)
Supports Kinect controls for the game addicts.
Many applications in astronomy - and likely in other fields - explicitly do not apply a DUT1 (or other EOP) correction because they assume that UTC is close enough to UT.
Many of these will have to start applying a DUT1 correction because UTC will no longer provide Universal Time.
The ITU-R proposal also is to stop issuing the DUT1 offset time signals. Some systems currently rely on non-standardized access to ad hoc resources such as you describe. Someone or some community will have to standardize these procedures and deploy battle-hardened infrastructure suitable for the increased load.
No engineering plan exists for work related to this infrastructure. The assumption is that it will just magically happen. Services will be designed, deployed, funded, operated, maintained - and applications will be rewritten to make use of them. Who will do this?
That you (or others) can't conceive of requirements for mean solar time implicit in various nooks and crannies of civil timekeeping does not mean that such requirements don't exist. A coherent systems engineering plan is the way to reveal such requirements.
One might think that those tasked with guiding missiles might prefer to have their engineers take a look at this before it is voted upon.
Maybe this change is a Y2K style jobs program. Nah, too few types of code are affected. It's not like my bank needs UT1 or barycentric dynamical time to the microsecond.
Y2K was a non-millennial event precisely because squadrons of crack programmers were deployed to fight the good fight. A Y2K inventory such as: http://iraf.noao.edu/projects/y2k/y2kplan.html, was a relatively straightforward exercise in pattern matching, but still required the examination of the entire codebase.
A similar UTC-clean inventory will be needed against a similarly broad codebase. It will not be a simple exercise in pattern matching. The assumption has been that whole industries and communities can ignore the whole thing. This assumption results from viewing the issue as being about ceasing leap seconds.
Rather, like the curious incident of the dog that didn't bark, the absence of leap seconds has broader implications, namely UTC will no longer be a type of universal time. Rather than simplifying civil timekeeping, suddenly two types of time must become explicit in the source and libraries of diverse systems that previously could assume they were the same thing.
Banks may not need "UT1 or barycentric dynamical time to the microsecond". But the error will accumulate six orders of magnitude larger than that annually, and many of the systems funded by the banks - air, land and sea transportation, GIS, communications, logistics in addition to science and tech - may certainly care.
The point is - nobody has looked. This is Y2K under an invisibility cloak.
Time is measured in sexagesimal fractions for the same reason that longitude is - they are both representations of angles.
TAI (also on the chopping block) and other interval timescales are appropriately represented as an open-ended count of seconds since some defining epoch.
UTC, as a type of Universal Time, that is time-of-day, represents the (mean) angle of the Sun in the sky.
Clocks report time-of-day, Universal Time, UTC - because vast numbers of human activities are diurnal. A sexagesimal representation is appropriate.
Chronometers - a different kind of timepiece - report precise intervals. A numerical count is appropriate.
The problem arises in converting between one and the other while making overly-simplistic assumptions about the interface design and underlying project requirements.
"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs