...Nobody? Which is why peer dependencies exist.
NPM/Yarn aren't perfect by any stretch, but maybe mind Chesterton's Fence and refrain from reflexively assuming the developers of them are idiots?
This has been reinforced over and over again throughout JS history. jQuery, Grunt, Gulp, Angular, Bootstrap, and eventually React will join that list as well. You almost always end up with the nightmare of having to do package management because widget A and widget B interfere with each other. This is the same exact reason why it's good practice to avoid defining JS variables in the global scope.
Peer dependencies are just global variables at the package level.
To be clear, the people who built NPM were not idiots. Node handles packaging really intelligently - via a node_modules folder. There was a lot of thought put into how to make this system flexible: for example, you can have a node_modules not just at your root, but even in subfolders. This allows you to have custom implementations of a dependency that's isolated to a single folder in your source code, and to easily check your implementation directly into your VC.
None of that is accidental - the Node developers learned from languages like Ruby and Python, where gems and packages would be installed globally to the system, not locally to your project. They wanted a system that got rid of the majority of peer dependencies.
Jump outside of the web world and you'll see the same trend in the broader software ecosystem as well. The big hotness around Linux packaging right now is Flatpack, which is mostly copying Node's strategy of bundling dependencies into the app and then de-duplicating them after installation. Docker is an even more extreme example of this trend.
Peer dependencies are sometimes useful, and they're an important concept. But people use them and abuse them too much. They sound like they should be a good idea, so developers often don't realize the downsides until after they've gotten bitten - and even then they often just assume they were using a bad library or something.
9 out of 10 times you should avoid them, and you should avoid frameworks that introduce them.
I'm sorry that you've gotten bitten because it's frustrating when it happens, but "if a package requires a peer dependency,it's probably not worth using" is some cargo-cult stuff. Anything that acts as a extension system (coded to an interface) should use the project it's extending as a peerDependency. They are not "global variables", they're interfaces. It's what you're writing against! If you end up in dependency hell because of them, that means your dependencies are not speaking to the same interface, and that means you need to resolve the problem. Which can suck, I guess, having to actually do some work as a programmer, but somehow I think we'll all muddle through. Because the alternative is to silently have different APIs that will later break because the extended system has changed, and that is rather worse than actually knowing what's going on in your system.
React is a system that exists to be extended. Peer dependencies exist to facilitate this. Understanding one's tools makes cargo-cult sweeping-statement fears about milquetoast stuff really just unnecessary.
Flatpak is whatever (it's fancy /opt, that's fine) but, "jumping outside the web world", I'll put on my platform-architecture-is-my-actual-real-job hat right now and point out that Docker, while certainly appropriate for some use cases, is, for example, happy to cost you money in production when your big ol' app (shouts to my 4GB-heap-before-taking-a-request Ruby clients) can't copy-on-write. (After all, each process is supposed to be isolated, right? I mean, that's what people think...) There are real drawbacks to this approach, it's orthogonal to actually writing code, and the analogy doesn't really hold besides.
