This has been debated for years, and parts of the answers is right above. Also, software is not a collection of biological organisms. And the local variables are not shared, so WTF anyway. The analogy makes no sense. Everybody is already neatly separated.
Proponent of everything static have yet to show non toy / very specialized systems where everything is actually static.
Let's avoid the strawman anyway and in this case, yes, some static linking can have its use, especially for some small utility / metaprog / etc. packages, although it has and will always have drawbacks to, especially for higher level feature support (e.g. a codec). You have to go into the specifics to understand which are more important depending on the context. Probably a mix is needed.
For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB, but maybe there are advantages so great that this is something we can live with. The net perf impact is extremely hard to predict and measure. You will duplicate tons of code, but arguably e.g. the cache overhead might not be extremely bad, we now have tons of memory, so maybe we can waste some, etc.
Note however that if a Linux distro is competing with other kind of plateforms, there is the risk to put the Linux distro at a disadvantage if the static vs. dynamic (maybe on a package per package basis) is chosen improperly, because other platforms make the distinction between platform and application, their platform typically provides a very large API, and they won't go the insane way and switch to static.
The lack of proper dynamic linkage story for Rust is a problem that needs to be fixed to enable some kind of usages. Not something that can always be worked-around (sometimes it can, and for some crate you really want static to begin with anyway)