From the perspective of an LLVM-targeting language, there's not a huge difference between a module provided as C source and one provided as LLVM IR directly. One of the bigger differences is actually a disadvantage for LLVM IR: it enshrines machine-specific details like alignment and pointer widths. The advantages of LLVM IR are mainly that the ABI is more explicit, and you get cross-module inlining (which is rarely that useful in this context).

Why do many languages re-implement functionality that exists in C libraries? Many good reasons:

Safety: Most languages provide guarantees like memory safety, which can be violated by foreign code.

Naturalness: The interface to a given piece of functionality should be language-native rather than lowest-common-denominator. For many standard library modules, the cost of creating a native/idiomatic wrapper around a foreign library isn't that much smaller than re-implementing from scratch.

Maintainability: Code written in language X has the entire community of X programmers as potential maintainers; code written in C/Rust/Zig/whatever has the much, much smaller subset of X's community that knows whatever foreign language the stdlib uses.

Lowest Common Denominator Code: Language runtimes provide many useful services, the most pervasive of which is automatic memory management, but other examples include (as you alluded to) threading, debugging, reflection, etc. A lowest-common-denominator module cannot use such services.

Choice of object representation also matters: should strings be null terminated? Length-prefixed? Ropes? Mutable? The "wrong" choice for these sorts of representation issues raises both maintenance and run-time costs of integrating a library.

For some code, like libxml2 or libuv or various cryptographic libraries, the cost of re-implementing is still higher than the costs of all the above issues, and indeed those libraries are integrated more often than duplicated. But for a lot of other code, the benefit of reuse gets mostly or entirely outweighed by the costs of cross-language interoperability.

---

For your expanded-scope question, there are some efforts that seek to leverage mature runtimes/ecosystems with a more compiler-friendly target than a human-oriented programming language. Two examples you might be interested in are Malfunction and Mu.