It's really weird to me that they're talking about balancing static vs. dynamic in terms of the dev-end build time speed vs running the software load times.
To me the dynamic vs static balancing act is about compatibility vs security where dynamic linked applications easily get lib security updates but the binary may or may not work with your system libs and statically compiling is more compatible but doesn't automatically get system lib security updates.
They are talking about app-bundled dylibs, which cannot be updated separately due to the whole-bundle signing.
In other words it's a fix for a somewhat Apple-specific (and in this case Apple-created) problem?
The problem is not Apple-specific and their solution could be useful elsewhere.
The specific optimization this achieves is during build time only: these new files are static libraries that are quicker to link. It is a small shift of some of the linking pipeline into the (parallel) builds of dependent libraries, rather than heaping it all onto the linker at the end of the build. The linker has to essentially re-link from scratch for every small change.
Parallelization has long been known as the best way to speed up linking. This Apple change comes in addition to rewriting their linker to be massively parallel. Mold did it first, though: https://github.com/rui314/mold
edit: lld did it first, mold improved upon it
A faster development cycle is one of the coolest improvements that Zig brings – lightning fast recompiles, bringing the native development cycle closer to web speed. More languages should get this capability, and Apple needs it for Swift to get instantly updating SwiftUI previews.
Static linking is required to get the best performance: no linker runtime cost, cross-language LTO and dead code elimination
If this optimization is generally applicable and developers find it worthwhile, I could imagine this making its way to GCC-land. At the very least, gold needs replacing/rewriting to be competitive now.
edited: for clarity