There's other perfectly valid reasons to use pure-JS on a large open source project, but the ES6 thing is a red herring IMHO.
The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then.
For me it's not hard to imagine a CoffeeScript 2.0 release at some point next year that targets ES6. It could make a few syntax changes, and ship with some helper tools (or a 3rd would create it) to detect possibilities in your previous code and tell you where you need to tweak to make it compatible.
Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then; there's no reason it has to happen now.
Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1]
It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".
Isn't the analogy here something like
CoffeeScript is to JavaScript as Closure is to the JVM.
Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?
[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.
So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.
But the new features of ES6 aren't features of CoffeeScript. Why would we expect them to be?
It's like noting that Java 7 adds support for strings to switch statements and wondering how the syntax of Closure is going to change in response.
There is no strict requirement for the languages to be tied together at a syntax level, they just "compile" to something compatible.
There may be strong technical reasons for the CoffeeScript compiler to take advantage of the new features of ES6, but that doesn't force a change to CoffeeScript-the-language. (In other words, it can target ES6 while remaining backward compatible.)
I wouldn't be surprised to discover I'm missing something, but I'm genuinely confused why this is seen as a technical problem. It's not that CoffeeScript-the-language is "not interested in the new features of ES6", but that, technically speaking, CoffeeScript-the-language is not interested in ES-the-language at all.
Apples and oranges. (Or maybe lemons and limes.)
As an aside, I do see this as a potential social problem. CoffeeScript would probably like to remain conceptually-compatible with JavaScript, and that gets much harder if the two have different semantics for similar syntax-es, but I'm going to guess this isn't the only example of it.
2) One may prefer a more explicit language, filled with semicolons, curly braces, and "function" functions.
That said, I personally would have greatly preferred it as CoffeeScript, which I use regularly on projects where the people I work with have the same preference.