Performance is a relatively minor problem here, complexity being the bigger concern. For example, I really love all-in-one programs like Rust's 'cargo' and Nix's 'nix', but the work that goes into making them work properly is astronomical. On top of that, both of those programs have limited composability and fight for dominance with other interlocking tools like rustc and nix-env, respectively.
My sense is that it takes a lot of savvy to make good decisions about the complexity of your design and the choices about which dependencies you rely on. This takes years of practical experience to learn, and the incoming generation of programmers will always be bad at it.
Young programmers have a tendency to err in both directions, here.
Some will err by building on lots of complex systems tied together. They’ll fire off “create-react-app” on day 1, and then on day 1000 they realize that there’s just too much going on that they don’t understand and can’t debug.
Some will err on the side of rejecting “heavy” dependencies. They overestimate their knowledge of the problem domain, underestimate the flaws in code they are planning to write. They’ll create a blank repo on day 1 and on day 1000 still be working on support code that they didn’t have to write.
If you have years of experience, it’s easier to navigate the middle path. The incoming generation will figure it out given time.
However, both sides need a good mentor that shows The Way to them, or just they tend to get stuck where they have started for a longer time than they should, IME.
