In general, I've come to believe that it's very easy to look at decisions as "severe cases of NIH" by looking at available tools and assuming that something must fit the bill.

Especially in the young ecosystem that is JavaScript, there are often areas where the existing out-of-the-box solutions just don't satisfy the use cases of other open source projects.

As Stef said, our first attempt was to build a grunt-based build solution, and it may still be possible to do so, but it wasn't as simple and drop-in as you might expect. When the work to build on top of existing solutions becomes significant, it's not longer an obvious and "severe case of NIH" to consider more home-rolling. Sometimes those home-rolled solutions even become useful for the broader ecosystem (for example, git).

I don't think that Ember should build a huge, monolithic build tool system tightly coupled to Ember. We're already looking at bringing together the best in breed of existing tools and working with people who are building other tooling components that satisfy some of our needs. We absolutely plan to use bower for package management, for instance.

NIH is a really easy accusation to throw out, but real life, especially with large open source projects and young ecosystems, is hardly that simple.