It's justified simply because the alternative -- overall -- is more work for less gain.
Virtually all computing systems (could argue: all systems, period) are built in layers. Each platform makes assumptions about what's below it.
ls assumes there will be a C standard library. Which assumes there will be a kernel. Which assumes there will be computing hardware. Which assumes there will be a steady voltage, etc.
By making those assumptions: I write code faster. I can do more. I don't care about bundling a C library, or a zip library, or a crypto library: someone else does that. And when someone else decides to improve or upgrade those components, I benefit transparently. And so do all other programs sharing that code. In a coherent system, it's faster, cleaner, smaller, better.
But, as you note, it is more dependent. And if crypto is upgraded in an incompatible way, I break, and package management becomes difficult. To truly decouple the kinds of deps that make package management difficult, components need to inline their deps. They need include more of the stack below them. And this is the crux of the issue: to create a program that has fewer dependences, we need a build system that understands more. And that's not where developers want to (or should) spend their time.
You describe the current predicament as "extreme coupling". People have experimented with making everything independent: checkout stali, a linux distro that aims to keep all binaries statically linked. But an extreme-decoupling would be just as debilitating: imagine one VM for every program.
The phenomenal growth of our industry is largely due to our ability to build rapidly on what's come before. Literally and metaphorically, we stand on the shoulders of giants. Maybe in the future, we'll swallow a giant as the first step of making one taller. For now, though, the compromise seems roughly correct: lets keep climbing, and make sure the giants below us play nice.