No argument there. You know not everyone gets to work under a 10x leader. Probably the median leader in any sector is -x, because the skillset required to raise money is not necessarily the skillset required to lead.
> The triangle has three sides: fast, quality, and cheap
I think that should not be a universal rule. You can leverage open-source solutions to cheat more than one of those sides, with a little bit of expertise, or by stumbling on the right framework by accident.
Dependency management, or the lack of, is one of those "be careful what you wish for" type scenarios. At my current team we perform a lot of manual copy/pasting of directories they many contain hundreds of not managed dependencies. I really think it would be substantially faster to burn it all down and do it right with few, or no, dependencies and an emphasis on automation at every level. That perceived speed increase takes into account the costs and lost time for reinventing many wheels.
The first thing I learned out of school was the developer's triangle. The triangle has three sides: fast, quality, and cheap. From the outside no matter where you stand you can only see three sides. If you want cheap its not going to be both fast and excellent quality. If you want fast its not going to be both cheap and great quality. Finally, if you want excellent quality its not going to be both fast and cheap.
It takes years for a developer to move from beginning through proficiency towards mastery. If you hire junior developers assume you are sacrificing both speed and quality for cheap. If you fail to develop your juniors your code will not achieve quality and your people will not become faster. Frameworks, or any layers of unnecessary abstraction, are not a replacement for training and experience. While this is mostly true for all platforms/technologies it is especially true for web technologies where everything is defined against the same set of standards that work the same cross browser and cross OS.
If your leadership were interested in product quality first then developers would be allowed to fail internally so that they could learn. You learn a lot from failure. It is part of growing, innovation, and making better product decisions. You separate the product from that learning through test automation, continuous integration, performance metrics, and automated complexity analysis.