Put another way: what makes this time different? How does this designer's proclivity and push towards X learn from our collective past mistakes; what does it bring to the table?

Yes dependency hell is "bad", but we have several language and package management systems today from ninja to uv that make various, obvious trade offs. Optimizing developer time, ergonomics, reproducible builds, configuration complexity are just some of the axes these pre-existing systems focus on.

If you're extremely lucky you get to pick a system that aligns with your style of work and ideals for how software should be built. If you're not, and like the rest of us, you get stuck with everyone else's poor decisions and are forced to make do. All code is legacy code given the right time horizon, so think about software with all those manual dependencies included on disk and nowhere else. How do you safely apply those required security fixes, etc. Don't be user hostile, this will just lead to our past sins like the C of old.

From a purist perspective, you can forgo all other software that you have not written in-house / or does not come with the standard library. This is the monk approach, but outside a few niche work environments that's untenable.