> HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that.

Yes they can? If you look at old-timey C libraries, for example (standard or otherwise), you’ll see that they have the relatively awkward structure of one public function per file. That’s an adaptation for static linking, which only pulls in the object files that contain symbols required by the program, thus it’s beneficial to make the object (and therefore source) files as small as possible. Yes, the compiler still needs to produce of these object files, but unlike with Zig it only needs to do so once per (separately compiled) library.

An inferior emulation of the same trick, popular in the embedded community, is passing --gc-sections to ld, but unless you’re very careful something will fall off that you weren’t planning on. (Of course C++ makes things more complicated, as always, so you may be forced to use this option.)

Glibc’s (and specifically Drepper’s) aversion to static linking did us all a disservice by making static libraries less popular.

This does not mean that there isn’t some benefit to whole-program compilation. E.g. GCC can derive assumptions about a non-exported function’s arguments and propagate them into the function’s body even if it does not decide to inline it (look for “constprop” symbols in objdump). So that’s also a thing that people do, in particular in gamedev where the somewhat stylized source code structure it requires is less of a problem. (Game developers confusingly call this a “unity” build—personally I prefer the term “amalgamation” used by Lua and SQLite.)