Then it would become impossible to store future timestamps in a database and have a stable answer to the question, "on what day will this timestamp occur?" Timestamps around midnight could flip from one day to another unpredictably depending on what version of the leap second database the formatter has. And that wouldn't just affect the leap second day, it would affect every day of every year. That would cause problems for many fields where calendar dates matter (legal and accounting, to name a couple). I expect we'd wind up avoiding the problem by saving dates internally as formatted UTC strings, and be back where we started.
That's true for software that cares about the ___location of celestial bodies. In those cases use UTC by all means as event markers. That allows you to count calendar days. However to calculate the duration between two dates down to the second you will still first want to convert to TAI to get the correct answer.
