Temporal API seems to be based around Unix/POSIX timestamps, which ignore leap seconds. In Unix time a day is always 86400 "seconds". This makes it trivial to do UTC calendar arithmetic into the past and future without recourse to a database and without necessarily having to deal with fractional seconds. Leap seconds are handled by the OS by repeating or skipping a second, or slewing the length of a second for some period before and after the leap second.
Most datetime APIs are fundamentally designed and intended for supporting calendar and wall clock operations for business functions. If you need SI seconds for scientific purposes, you really need to use alternative APIs and facilities that provide and guarantee the semantics required all the way down to the hardware level. Likewise, if you want timers, etc, for software facilities like thread sleeping, you use dedicated interfaces like monotonic clocks. If leap seconds are phased out, this won't really change the situation. It was wrong for software to rely on Unix timestamps for, e.g., mutex algorithms before and it'll be wrong if and when leap second clock adjustments are gone.
Most datetime APIs are fundamentally designed and intended for supporting calendar and wall clock operations for business functions. If you need SI seconds for scientific purposes, you really need to use alternative APIs and facilities that provide and guarantee the semantics required all the way down to the hardware level. Likewise, if you want timers, etc, for software facilities like thread sleeping, you use dedicated interfaces like monotonic clocks. If leap seconds are phased out, this won't really change the situation. It was wrong for software to rely on Unix timestamps for, e.g., mutex algorithms before and it'll be wrong if and when leap second clock adjustments are gone.