I’ll try to, but there are others who might be able to do a better job than me. And also, “a cool thing” is kind of subjective, so there might be some disagreement in this area.
I think first to understand why, you have to understand some of what an addon can do. The most primitive and obvious use case for an addon is just including ember-based runtime code, plugins for your app (eg
ember-truth-helpers). But the real brilliance of Ember CLI’s architecture (and Broccoli too) is that it’s completely pipeline driven and addons have the ability to modify that build pipeline! So think about an addon like
ember-cli-sass, it doesn’t provide any ember-based runtime code, it’s all build tool and preprocessor related, but ember-cli doesn’t really distinguish between these addons.
So now imagine an addon that has both ember-based runtime code and build pipeline related code. Your addon can do things like including extra code for development, inject its own test helpers, provide better/smarter minification steps, allow for individual file importing, etc. In fact, the addon itself can be built as part of the application’s build step. Rather than what we have now in many cases where the addon is build into a single distributable JS file with other debug files (like source maps), then ember-cli tries to “unpack” that all again for debugging.
So that’s the power of the Ember CLI addon model. When it comes to Ember becoming an addon, I don’t know exactly what their plans are. I can imagine we’ll see more debugging tools and maybe even some preprocessing and minification improvements. But one other thing I can imagine that will nice is you could easily try out bug fixes in your app with a simple package.json modification. No manual js building required. You could also use your app to help debug and fix issues with ember.