I suspect the reason it went through is because it _actually_ modernized the codebase: unlike previous ideas, just swapping ES5 notation for a newer slightly more efficient ES6 notation, this refactor actually changes the load, parse, and bundle efficiency of the codebase, from a non-standard module style to what we've now collectively agreed on JS-native module should look like; something that before ES6 simply did not exist. There were choices made by individuals or organizations (commonjs, umd, etc), but only as of ES6 are modules _actually_ a formal construct in JS, with an official spec that formalizes how imports work. Any code changes that bring older codebases in line with the new spec are fantastic: this codebase just got massively future-proofed without any impact whatsoever on its integrity.
(the one example that didn't run turned out to be a bug in the current example, not in the refactor)
I'm all for bringing Three.js up to date and applying modern JS tools to it. The maintainers of Three usually push back against these efforts. This PR still doesn't address the many fundamental problems with the quality of Three's source code and the attitudes of the maintainers. I wouldn't personally use Three on a large project, the low quality ecosystem will eventually harm you. It's designed as library to spin up small projects quickly. It's good at that. Beyond that I wouldn't recommend it.
For the record I believe Babylon (another WebGL utility library) has similar problems with the source code. I don't have a suggestion for the "best" WebGL library to use.