As for static libc: please don't do this. A static libc, from a compatibility POV, is just as bad as embedding random SYSENTER instructions in program text. It makes the system much more brittle than it would otherwise be. I understand the desire to package a whole program into a single blob that works on every system, but we should support this use case with strong compatibility guarantees for libc, not with making SYSENTER the permanent support boundary!
When I am god emperor of mankind, on my first day, I will outlaw both static linking of libc and non-PIE main executables.
Preaching to the converted here, I'm a big fan of dynamic linking. It seems that while Go binaries are generally statically linked (last time I checked, which was a while ago), that libc is generally dynamically linked for the reasons that you have stated, also also because some features like NSS require dynamic linking to work correctly.
Disclaimer: I mostly program in C and C++, not Rust or Go (yet).
> If all programs need to go through libc, doesn't that mean they are all equal?
It means that all programs need to link libc into their binary, whether statically or dynamically. Part of the reason-de-etre for Rust seems to be as a replacement for C and C++ so it would seem peculiar to me that the C library would become a forced dependency for compiled languages like those. But as the other poster pointed out, you can disable it anyway, so no matter.