The problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.
You would be right if vendors weren't able to deliver time zones in time. In practice they are, though with lots of headaches. We can just piggyback on the existing infrastructure of the time zone distribution with no additional cost.
I don't think this infrastructure you're relying on exists. A great deal of software isn't maintained at all. It was built once by a contractor and has been plodding along doing its work for decades.
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.
It should be very visible to users that softwares are unable to keep with time zone changes anyway (including those due to the relocation). If they are able to keep up somehow, probably manually, then leap hours don't impose any additional requirement to them.
Or, you can abolish the time zone to make software developers very happy [1]. At the expense of everything else.
If you don't do any tzdata updates in a century then I can guarantee you that the application will be showing wrong local times anyways. Timezone changes happen. That is a already occurring thing.
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.
