This is a nice overview. It about matches my perception of things too. But I would want to ask:
Why don't existing datetime libraries (outside of Rust) that offer a high level and convenient API support leap seconds? I'm thinking specifically about TC39's Temporal project. That project has gotten person years of experts carefully thinking about datetime. If you read their discussions, it's very clear that they care deeply about avoiding footguns and getting things correct. Yet, they almost entirely punt on the leap second issue. Why is that? My favorite explanation is "it doesn't matter that much." But I don't know for sure. Most leap second bugs I've heard about are really just bugs in systems that assume the system clock is monotonic. I don't think I've heard about bugs related to "the span of time computed was one second less than it should have been." I can obviously imagine use cases where that really does matter (scientific calculations or medical devices), but those use cases typically have more specialized datetime libraries available to them. (I'd put hifitime in this bucket.) I've searched for an answer to this question and I've yet to find a satisfactory answer. ("because programmers don't want to deal with them" might work for any given individual programmer, but that doesn't fly for me in the TC39 case.)
I'd also inquire about DST transitions. Those seem like something that is far more likely to bite you than leap seconds will. I believe only chrono-tz supports them.
Finally, I think you missed icu_calendar (along with some other crates in that family like icu_timezone) in your analysis. Although there do appear to be some critical concepts missing there (durations?), it's hard for me to say because I've found it difficult to get a handle on what the API offers. Clearly though it does have support for many different kinds of calendars and is also taking on the i18n task.