It would be counter-productive. For example on a Clang/Musl only system; I can add an environment variable such as LD_PRELOAD to preload Microsoft's Mimalloc in order to HUGELY increase threaded performance compared to native memory allocator in Musl.

Statically linked binaries are significantly larger in size. They consume more disk space. They use more RAM when running. This is especially problematic for systems with limited resources.

Static linking makes it harder to patch security vulnerabilities. Each application would need to be recompiled and redistributed for every security update.

Dynamic linking allows for better memory sharing between processes. Static linking can lead to slower startup times for applications. Overall system performance may degrade due to increased memory usage.

Hardware-specific optimizations become more difficult. Applications may not take advantage of newer CPU instructions or features (unless recompiled and distributed). There is a possibility for potential conflicts with system-specific configurations or hardware.

Developers would need to maintain and compile binaries for multiple architectures. This means increased complexity in build systems and continuous integration pipelines and higher chances of introducing bugs due to different compilation environments.

Users would lose the ability to use alternative versions of libraries. System wide tweaks and optimizations would become more challenging. Customization options for advanced users are reduced. For example, I am a Gentoo user. I do in fact statically link some binaries but having the ability to dynamically link them, open the possibility for customization.

Compiling statically linked binaries takes longer. More powerful build systems would be required. That means higher storage and bandwidth costs for distributing larger binaries.

Applications may include outdated or conflicting versions of libraries. Inconsistent behavior between applications using different library versions is possible. There are potential licensing issues with statically linked proprietary libraries.

Distribution maintainers can no longer optimize packages for their specific systems. Performance benefits from distro-specific patches are lost. This also means reduced ability to integrate with distro-specific tools and features.

Users would have to wait for developers to recompile and redistribute entire applications.

Existing package managers would become less effective. Dependency resolution and tracking would be more difficult. System-wide updates would be more complex and time-consuming.

Each application would include its own copy of libraries. This is a security vulnerability since we also don't have sandboxing in this case. More code means more potential vulnerabilities. They could exploit outdated libraries bundled with applications.

Users would need to download entire application binaries for small updates. We are trying migrate to atomic updates with very little changes. This would become the exact opposite.

Debugging statically linked binaries is more complex. Stack traces become less informative. Identifying the source of issues becomes harder.

The shared effort of maintaining and improving shared libraries would be destroyed.

Complying with licenses that require source code distribution becomes more complex. You need to make sure that all statically linked libraries' sources are available and matching.

Dynamic linking allows for some runtime optimizations and replacements. Some performance enhancing techniques like prelinking become impossible.

Some security mechanisms rely on dynamic linking, such as ASLR. Implementing certain sandboxing techniques becomes more difficult.