That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds.
I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway.
For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.
The lookup database is incredibly small and updated very infrequently. Certainly smaller and less frequent than tzinfo which is also included in the kernel
AFAICT leap seconds are announced about 6 months in advance (January/June). How would you process times that are to occur after a leap second that may or may not be?
You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.
I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway.
For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.