No, and yes, and anyway it doesn't matter.
No, that wouldn't be the case. If you mess up the local->global conversion, you'd still be hours off, not just seconds. Realistically, we would probably need to define TAI2 = TAI + 35 seconds and then switch to that. Then the only immediate change would be that we'd stop adding the leap second flag to NTP updates. If you were doing UTC conversions correctly before, you'd automatically be doing TAI2 conversions correctly after, but if you mess up that conversion, you'll still be hours off.
But yes, such a change would introduce a new problem: Software or systems that are not updated to handle leap seconds in offsets might display localtime a second or two off.
Still, it wouldn't matter much. Non-TAI2 systems might display localtime a second or two off, but their clocks would still be correctly synchronized. Having an incorrect offset would be like inadvertently defining your own custom timezone. Nobody else would care about your timezone (whether it's a standard one or not), because you'd be communicating with them using global time based on your correctly synchronized clock.
Instead of converting from UTC to Local time, you'll be converting from TAI to Local time.
If seconds matter you should be testing seconds. I submit that being off by 3 seconds all the time is an easier mistake to catch in testing than "explodes every time there is a leap second".
Now, instead, imagine things being only a few seconds off, instead of entire hours. How big is the chance that the bug would be caught before things hit production? What if, in some cases, seconds actually matter?
I think it's just asking for trouble.
To me, this is a bit like proposing binary protocols and not text protocols because it's obviously technically superior. It's a good idea until you factor in that software is made by humans.