We target a platform that has arrow functions, we don't need to compile them in any more. Not a big deal for arrow functions, but a HUGE deal for async/await, or for-of statements (both of which will compile to a LOT of code which includes a pretty large amount of runtime-checking to work).

But there's also the fact that you do pack some of it into the final build. Many transformations include a lot of boilerplate, "helper" code, and in some cases big polyfills. Getting rid of those when possible is a huge bonus. And Babel 6 paved the way to allow you to incrementally remove those plugins one at a time as your target platform supported the feature natively (and at a speed that you are comfortable with). We currently only transpile async/await in one of our codebases, once that lands in node.js and is stable, babel will no longer be part of our pipeline. That's not something that we could have done easily with the Babel-5 system.

But it also takes babel from a "ES6 -> ES5" tool and makes it a general compiler. Babel now has plugins that will minify the code, plugins that will drop dead code, plugins that can perform "GCC style" optimizations in terms of IIFE removal, constant inlining, loop-unrolling, and more. Before the Babel-6 change, all of that would either need to package it's own AST parsing, or it's own bastardized version of babel. Now it's as easy to write plugins that do things like remove the prop-type code from a React project [0], or eliminate unnecessary closures [1].

There's also the ability to save space and install time on the developer machine. Not that big of a deal to me, but I hear others complain about it from time to time.

But those are just the reasons why I like that it's modular.

[0]https://github.com/oliviertassinari/babel-plugin-transform-r...

[1]https://github.com/codemix/babel-plugin-closure-elimination