The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes.
We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after the leap hour (hereafter UTC'). After the leap hour UTC and UTC' will coexist, where UTC' = UTC-1. Since time zone definitions themselves have UTC offsets, the trick is that instead of replacing all occurrences of UTC with UTC' (so that they would have UTC' offsets) we replace those offsets to have the same net effect. For example EST is UTC-5 before the leap hour and UTC'-5 = UTC-6 after the leap hour, so we pretend that the definition of EST changed to UTC-6.
Note that this approach essentially fixes the UTC-TAI offset (as opposed to the UTC'-TAI offset) and makes UNIX timestamp (time_t) deviate from the current version of UTC (well, UTC'). I believe this is just a matter of definition and thus much doable than changing UTC every few year. After all, leap hours would be much rare, probably the first one would occur at least a few centuries later.
Major software vendors won't have any particular trouble, but neither did they have any trouble in 2000. It's all the tail-end stuff which is in danger of breaking.
Or, you can abolish the time zone to make software developers very happy [1]. At the expense of everything else.
And it's not like there is even hard deadline to do the changes, nor would it come unpredictably. If any schedule we set would seem problematic, the change can be deferred by another decade or two to get systems fixed if really needed.
tzdata updates happen all the time (in a relative sense). So code would need to handle those, and I don't see why potential leap hours couldn't be handled like that. Just means that Europe/London eventually will be +01:00 (or is it -01:00, anyways) instead of +00:00 its now.
But, leap hours don’t need to be co-ordinated: countries can and do change their clocks to adjust the time of sunrise when they want.
And leap hours will work much longer than leap seconds: leap seconds will become too frequent in 1 or 2 thousand years, but leap hours will just be getting started. See the second table at the same link https://www.ucolick.org/~sla/leapsecs/dutc.html
You are however right that this is a political matter requiring some (but I believe, reasonable) amount of coordination, but timekeeping is in many parts political anyway. Practically speaking countries would implement the change out of necessity and not because of agreements, as one hour deviation is significant enough.
Who is we in this sentence? Programmers certainly don't, they have to report times and timezones in their software as the populace expects it to be reported. Governments can change timezones, but they're not going to, because the political cost of telling everyone that they're in a new timezone is greater than the political cost of telling programmers where to shove it.
Most of the public will see absolutely no reason why they should have to permanently change the timezone they're in for the sake of a one-time event. And honestly, even as a programmer who'd be doing the fixing, I agree that they're right.
We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fifth of the way to the next one (not to mention the timestamp bug one coming up in a decade).
I disagree with the other comment's suggestion that leap hours can be taken into consideration like DST. I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.