In Clojure(Script) it seems to be a net positive because of the curation effect - the community generally has good taste in picking the good parts of the JVM/npm ecosystems and packaging those to for wide use. For example the de facto standard logging library doesn't use log4j but can interop with Java logging stuff and presents the same interface on both ClojureScript and JVM.

(Also many Java libraries have imperative APIs for no good reason, and it's sometimes the wrapper can present a functional interface)

The reason being that they are older than Java 8, and not everyone buys into functional styles.

Even on .NET, with LINQ having been introduced in .NET 3.5, there might come up some PR discussions that I will just give up and rewrite the code to the expectation level of the audience.

That's true to some extent of the native language as well. Hibernate, for example, is a java(-bean) idiomatic wrapper on top of JDBC. Same goes for Log4J being a wrapper of java.util.logging, etc. Not quite the same thing as what Scala or Clojure have done, but far from just sticking to the basics.

It's one thing to build a wrapper on top of a comprehensive standard library, and another thing altogether to build what is essentially an alternative standard library.

I think calling Hibernate "a wrapper around JDBC" is overreaching. A wrapper brings to mind (at least to me) this idea of a thin layer, mostly a simple translator between two worlds, but in this case there's tons of added complexity and pitfalls on top of JDBC, and there's the whole ORM deal with attending object-relational impedance mismatch, the whole "ORM is the Vietnam of Computer Science", and a completely different can of worms!

Writing higher level abstractions for ease of use in same language as the platform is written on, and creating wrappers just because it looks "ugly" to do direct FFI calls to the host language isn't really the same thing.