The number of CVEs is for the most part a function of how-often-does-someone-look-at-it and only for a tiny part a function of safety. If I remember correctly, sometime ago a lot of CVEs appeared for OpenBSD, because someone seemed to have started looking for vulnerabilities and found a lot of quite trivial but severe ones. Therefore I am somewhat concerned about the the OpenBSD-libc, but neither have I looked at the code nor am I an expert. I see the point that the wrappers are probably safe, but yet the full libc is loaded and available for malicious code.
But to be fair: The libc is able to handle – either by caching or by implementing the functionality – some syscalls without actually invoking a syscall and such a library allows to have an unstable API for syscalls and might allow other mitigation tactics.
As a compromise: Why not multiple libraries (libc, libgo?, librs?) that are allowed to do syscalls? Yes, a larger code base to maintain but imho enforcing a single library is worse.
At least for rust, a librs would be hard to create due to the lack of a stable ABI. So even if you did a pure rust libstd (like the now defunct Steed[0]), you'd still need to either manually link that libc (breaking the mitigation), or rebuild your program each time the distro updates either libstd or the rust compiler.
I'm not sure what the situation for Go is. Assuming Go has proper support for dynamic loading and a stable ABI, it would be doable.
Musl[1] for one.
[1] https://www.cvedetails.com/product/39652/Musl-libc-Musl.html...