Getting the mapping function wrong will only result in displaying a human readable time wrong. Databases, and in fact all systems, should use TAI-UT1 internally and across computers. And only convert to something else when displaying a human readable string.
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.