I'm closing this as a duplicate of T344638: Abilty to load compacted versions of javascript and css pages.

See also:

• T27845: Support loading wiki pages through mediaWiki.loader.load()
• T29281: Add support in the front-end for loading wiki pages as resources
• T29535: Add support for loading wiki pages as scripts/styles in ResourceLoader

In short: The bandwidth benefits are very minimal in practice compared to the outsized infrastructure and complexity required (both to build, deploy, maintain, and operate; and for users to discover, understand, and make use of). The reason is that gzip compression automatically takes care of the biggest gains already, and for any given user, we already leverage CDN and browser caching, thus avoiding repeat downloads for the same script.

There is of course a small benefit to be had by applying minification, which is why ResourceLoader exists for widely used scripts, and this is exposed to user-maintained scripts via the Gadgets extensions. Once a script is sufficiently widely used that a gadget makes sense, which requires a little bit of effort to adopt, all the other minification and bundling benefits automatically come along. The cost/benefit of building a second separte system for this, does not make sense I think.

Relevant future ideas:

• Improve caching of action=raw: T279120: Make index.php?action=raw CDN cacheable for both logged-in and logged-out for import script use case
• Improve gadgets:
  • T31272: Implement Gadgets 2.0
  • T36958: User-level gadgets (aka "Gadgets 3.0")

Too bad, but I can see where you're coming from. T36958 sounds super interesting.