This isn't completely a browser monoculture issue though. It might be part of the issue, but it's very likely because most big applications use tooling that hide this issue, i.e. using tools like Babel which just translate let/const into var automatically. I imagine it's never really been noticed because it just never really has been a "real world" problem.
You make a good point that a Babel configuration targeting pretty old browsers would convert const/let to var, though I don't think you can say it necessarily isn't a "real world" problem. It could very well be a real problem for a significant (Safari-using) minority of users, who don't see it as a bug and so it never comes to the attention of developers, but continues causing subtle headaches for thousands of people.
You misunderstand. The problem is that all the devs, and something like 3/4 of regular users, all use Chrome, meaning something like this can fly under the radar, going unnoticed, and make Safari or Firefox a second-class experience. It's only a "problem with Chrome" insomuch as Chrome has an unreasonably large market-share.
Definitely not, at least in the case of front-end devs. Speaking as one myself, part of this is that Chrome's dev tools are so much better. Part of it is that the great majority of your users are on Chromium, so that is the most important case to test. But of course it's a self-reinforcing cycle: the more devs that only use Chrome, the more apps that work best on Chrome, the more users that switch over to Chrome, the more devs who only feel the need to test on Chrome, repeat.
To add: any project or random script that hasn't at least considered babel/webpack probably isn't at a point where they would notice a 10x slowdown - the difference could be 10ms vs 100ms.
