The problem with a system that incorporates leap seconds is that you can't calculate time in the future. Leap seconds happen haphazardly and so can't be predicted.

POSIX defines a day as precisely 86400 "seconds". That makes date-time calculations incredibly easy. Then, using a database of historic leap seconds, you can convert to UTC, TAI, etc quite simply, albeit without being able to pinpoint the precise UTC second during days with a leap second. Also, your _future_ POSIX timestamps will always remain valid, regardless of how many leaps occur between now and the future timestamp.

Of course, POSIX timestamps are really only useful for civilian date-time applications. (Which fortunately is pretty much all anybody cares about.) A POSIX "second" isn't the same as the SI second. If that doesn't cut it for you, then you really need to use TAI (UTC is kind of a half-measure). But then you effectively forgo easy date-time manipulation and display, particularly for future dates.

Admittedly, the Go code is a little misleading. Their calculation of UTC is imprecise, and can be off by a second here or there, although the day, month, and year will always be correct. But the same holds for Unix and, AFAIU, Windows as well.