People have already gotten tired of the JavaScript framework/build system/distribution tool bang. Improvements need to be more than incremental before people will choose to learn new APIs and be able to find new package ecosystems.
I like to play with new ideas, and some of them don't end up hitting critical mass, but I appreciate their creation all the same. Often, they cause me to reconsider approaches I've taken on other projects.
I'm starting a new project tonight and will give this a go. It may not work, and all I've lost is a few hours. Creation for creation sake is what we should be about. Not everything should be about differentiators, and productivity gains. Sometimes, it's far more rewarding to just create, or to use someone else's creation. Almost every painting I have ever seen did nothing to differentiate itself in style, but I'm glad every single last one of them was painted.
Gulp uses streams, this uses generators. Some folks may like the look and feel of generators more than streams.
If it came with a set of modules for other packages so people could at the very least try the demo version before they buy into it, and it really is that much cleaner and more powerful, then I think people could really get behind it.
The trick to making a successful JS package nowadays is marketing, honestly.
I find it disappointing how some people have such an allergic reaction to others trying something new. If you don't like it, don't use it.
Which is a valid point, IMO. When there already multiple widely-used tools that do X, marketing your new tool as "Does X!!!" isn't very compelling in itself.
The first thing I want to see on the project page is something like "Why you should use this new tool over existing proven build systems with already flourishing ecosystems".
Moving from callback-based programming to generators + promises is like going from burning logs in dirt pits to gas stovetops. A build tool that incorporates it successfully deserves a hard look, at least.