In 1972 it was decided that the best way to compensate for this is to insert (and sometime remove) leap seconds, so that the difference between UTC and Earth’s rotation is kept below one second. A certain subset of astronomical and navigational/satellite applications rely on that condition being true. If this is changed, some decades-old systems, some of which may be critical infrastructure, may have to be substantially modified to account for leap seconds in some other way. The mention of GLONAS in the article is one such example.
In the international standard body responsible for UTC (ITU-R), there was up to now no sufficient majority in favor of abolishing leap seconds, due to those concerns. (Never change a running system, so to speak.) By now it has become apparent that the benefits of dropping leap seconds should vastly outweigh the potential drawbacks, at least for the next few decades. But it took some time for that realization, and probably also some older participants whose minds couldn’t be changed to die off.
GLONAS and other GPS like systems already have to deal with the temporal effects of special AND general relativity in their time keeping. Pushing leap seconds off on to the already special case system seems like a fair trade for making every other programmer and sysadmins life easier. let the extreme corner cases deal with their problems not everyone else.
I like to think that applications should be written under the assumption that the computer could be used by time-travellers, with the clock reflecting the respective changes to “local” time. That is, you would have calendar dates and wall-clock times reflecting the time travel, plus an elapsed-time clock reflecting the CPU’s subjective time. Then design your systems around that. As a consequence, they should also be immune to leap seconds and DST switches. But I guess that’s too much to ask. ;)