However, if newer versions of libc or the kernel are not backwards-compatible, that's a failure in the system itself (not the packaging). (Linus, as an example, has a strict rule about not breaking userland applications due to kernel changes.)

It's impractical (and undesirable from a security and other standpoint) to statically link all dependencies into every binary simply to "simplify" packaging. Not only would that be a waste of storage space and memory, but it prevents fixes (security or otherwise) applied to the libraries used by the application from taking effect without patching everything that statically-linked it.

Even if you ignore the storage space issue with some amount of hand-waving, larger binaries means greater I/O and network bandwidth requirements, which means it takes longer to update systems or create images for deployment. That in turn leads to increased downtime or increased sustaining costs, which effectively leads to reduced availability of the system.

This can be mitigated somewhat by using difference-only-style update mechanisms, but it only partially mitigates the issues created by statically-linked binaries; it does not eliminate them.

Dynamically-linking dependencies also ensures that future performance and security updates don't require a rebuild of existing applications; you can simply update the dependency, and if done properly, every application linked to it will automatically receive the benefits.

Obviously, if a given dependency is only ever used by a single component, and the component is always rebuilt when the dependencies are, it doesn't matter if they're statically-linked. I'm referring only to the system dependencies common to many system components (such as libc).

In the end, a carefully chosen set of dependencies that provide robust backwards-compatibility provides the least downtime and the most compelling administrative experience.