The initrd/initramfs serves to provide a minimal userspace required by more complex root storage arrangements before we can pivot root.
Sure I can reboot a system with hosed dynamic libraries into its initrd and use that userspace to try fix things. But I can also reboot onto any other rescue medium. The moment you've introduced a reboot into the recovery process there's myriad solutions, the introduction of the initrd didn't make a significant difference in this regard.
The historically statically-linked /bin /sbin stuff (yes, once upon a time not everything was shoved under /usr like the post-systemd world) could be used to fix broken dynamic libs without even requiring a reboot.
Zbyszek's comment about systems being cattle is very telling. What the hell are the these guys running on their laptops/desktops? I can see that attitude if you're only considering GNU/Linux as a substrate for running cloud instances and containers, but I use GNU/Linux as my main personal operating system on systems I absolutely do not view as cattle.
Grrrr.
The Fedora docs also describe two further rescue and emergency modes available from the grub menu: https://docs.fedoraproject.org/f27/system-administrators-gui...
Now I see people tout statically-linked binaries as if it's some kind of new thing brought by Golang and Rust. Though this may be a result of modern glibc being somewhat hostile towards and incompatible with static linking, so maybe the blame should fall on GNU for that one.
Netscape used to distribute statically-linked binaries for a number of *nix platforms as a way to avoid this problem all the way back in the 90s. All it needed was an X display server and stable kernel interfaces.
Eventually GNU/Linux changed to the point that everything was dynamically linked to the point that only `sln`, a statically linked `ln` was all you had to work with in lieu of a working dynamic linker to fix the system.