It's interesting that you see module systems and optimizing compilers as two parts of a whole. My impression of the two systems has always been that they're at best complimentary, with some impedances between the two.
For example, in the last large js project I was on, we found that the closure compiler by itself - even without ADVANCED_OPTIMIZATIONS - did well enough at optimizing the code that a separate module system wasn't worth it in terms of additional time to refactor.
You had a set of modules and compiled them into one file and did not use a module system - I am still naive on modern JavaScript work so any guidance gratefully etc.
We had a large codebase already, written with just script tags in mind, and we were being murdered by blocking loads of the javascript. I looked into refactoring to use something like require or labjs that loads without blocking, but would have taken a substantial amount of development time (this was a problem with the existing codebase of 8k lines or so, not the tools.)
While we were looking at that, I found that we could make our performance target by concatenating all the source together, running them through closure, and just serving up one monster js file a little under 1MB in size.
This was an enterprise system, so we could assume certain levels of client performance that cat picture industry applications probably can't, as well as having a lower bar for performance in the first place - a five second load time on a low performing system was firmly ok, so YMMV.
For example, in the last large js project I was on, we found that the closure compiler by itself - even without ADVANCED_OPTIMIZATIONS - did well enough at optimizing the code that a separate module system wasn't worth it in terms of additional time to refactor.