Perhaps this is just a Linux distro thing, but as someone who closely monitors the Void packages repo, dynamic linking burdens distro maintainers with hundreds of additional packages which need to be individually tracked, tested and updated.
(Packages which could otherwise be vendored by upstream and statically linked during the build.)
Dynamic linking also adds complexity to distro upgrades, because dependant packages often need to be rebuilt when the libraries they dynamically link to are changed or upgraded. For example, Void’s recent switch from LibreSSL to OpenSSL borked my install script which wasn’t aware of the change. It resulted in a built system whose XBPS package manager couldn’t verify SSL certs. On Arch, AUR packages were notoriously prone to dynamic linking errors (back when I still used it).
Personally, I don’t find the bandwidth efficiency and CVE arguments for dynamic linking to be all that convincing [1]:
Will security vulnerabilities in libraries that have been statically
linked cause large or unmanagable updates?
Findings: not really
Not including libc, the only libraries which had "critical" or "high"
severity vulnerabilities in 2019 which affected over 100 binaries on
my system were dbus, gnutls, cairo, libssh2, and curl. 265 binaries
were affected by the rest.
The total download cost to upgrade all binaries on my system which
were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0
GiB if you eliminate glibc.
It is also unknown if any of these vulnerabilities would have
been introduced after the last build date for a given statically
linked binary; if so that binary would not need to be updated. Many
vulnerabilities are also limited to a specific code path or use-case,
and binaries which do not invoke that code path in their dependencies
will not be affected. A process to ascertain this information in
the wake of a vulnerability could be automated.