It looks like iojs is only going to ship features once they've shipped in Chrome without a flag. The compelling reason to use the features is that they're useful!
EDIT: I don't think anyone is going to be sympathetic to holding back from using conveniences because people are choosing to stick with an old runtime. It's a different ballgame than the browser.
I would make a strong cut between "application code" and "library code". For the former compilation to ES5 is overkill because the author of the code controls the runtime. For the latter the library either has to contain a long list of "tested with the following versions of the following runtimes and with the following versions of the following ES6-to-ES5-compilers" or it should be compiled pre-publish into a format with known semantics.
Example: I wanted to use the WHATWG streams code. But then I realized that they used an ES6 subset that is currently only compatible with traceur. The result: I had the choice between patching the code or downloading traceur, compiling the library, somehow get traceur out of it, and then require the resulting file into my otherwise fully working ES6 environment. I take a nice, tested, ES5 version any day over that experience.
If the audience of your library is literally just one version of iojs and nothing else - then yes. But that seems pretty restrictive. Especially since we just reached the point where reusing libraries in different contexts (browser/node) became viable. I really hope we won't throw that away.
EDIT: I don't think anyone is going to be sympathetic to holding back from using conveniences because people are choosing to stick with an old runtime. It's a different ballgame than the browser.