All that said, I'm a fan of lisps, I've just never used one in production.
In Clojure, those all exist, generally by simply reusing the ones that Java or Javascript already invested time and effort into building, though sometimes it has its own as well.
The other type of library are generally conveniences, they either simplify existing APIs, add programming constructs, or template/establish a pattern for doing something. These are the ones you tend to not need as much in Clojure, because the language is already so expressive and succinct, and it is pretty trivial to implement your own custom conveniences directly focused to your application needs and your personal preferences.
As an extreme example, consider NPM's left-pad that caused such a huge mess when it was pulled by its author. It's not good that JS has a left-pad package, because it just shows a gaping hole in what should be JS's standard library.
Slightly more abstractly, Clojure's data-oriented paradigm makes a lot of libraries from other languages redundant, because you can simply map and reduce and assoc Clojure maps instead of writing boilerplate.
The statement should not be taken out of context from the rest of the paragraph, which includes, “These libraries are also generally very high quality…” This means that the two or three libraries you find are more likely to handle all of those edge cases you mentioned. Some libraries haven’t been updated in years because they’ve solved the problem they set out to solve, and nobody’s found a fault with them since then.
The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.