So you are worried about coping with leap-minutes. Yet every 4 years, except every 100 years, but including every 400 years we have a leap-year. I don't see that blowing up every time. Most places in the world change the clocks by an hour every year. We have leap-seconds thrown in on an almost annual basis.
Personally, I prefer leap-seconds to leap-minutes, but both are as trivial as anything to cope with. The way you normally cope with time slippage on computers is simple. You routinely check your time against a known reference (time servers or something getting time directly from the atomic clocks). If you are behind, move time up to match, if you are ahead, stall time until you are on time. For most people and most applications you would never notice the difference.
A few hard-realtime systems might have issues that might take a little working around. But these are issues that people deal with already for leap-seconds. There are some systems that need reasonably accurate time but aren't hard-realtime, for example cloud data sources that are updated from multiple locations.
I remember a particular example that was a lot of fun to deal with back in the late 90s. Our network techs botched an installation of a radio sourced atomic clock to our production Netware 4.11 servers. Basically they put the clock in a place where it couldn't receive the radio signal and it didn't fail good. One of our Netware servers ended up deciding it was 30 years in the future. This is a big issue for Netware because writes into the cloud based directory structure (the NDS) are timestamped to resolve contention between multiple writers - the most recent time of an update is taken. When you get a future time written in the NDS, the system copes using a mechanism called synthetic time. Basically Netware stalls time on that particular partition until realtime has caught up with the future time stamp. Unfortunately, when your timestamp is far in the future (like 30 years) this takes too long. So the next strategy is a process called declaring a new epoch. You essentially re-timestamp everything in the partition to a new start epoch time which is basically now. We tried this and it failed. In the end, I remember having to escalate the issue through Novell all the way to the back-end techies, who remote logged in to our network and fixed it with some unpublished switches on admin commands.
Generally though, especially with the design of modern OSs, time has become a much easier topic. The only people who really care about the difference between UT1 and UTC are people working on hard realtime systems with a timing need. GPS is the obvious example. But the GPS people already have a robust way of handling all this.
Overall, it is a bit of a meh story, being whipped up into a frenzy by the British newspapers because of a slow news day.