In my experience all non-trivial frontend project I've worked on have ended up with some kind of build step (minification, linting, concating, ect), with or without a compile2JS language.
This isn't an issue for node projects as you can simply `require` the `coffee-script/register` module and node handles coffee scripts for you via normal `requires`.
I'm not sure that's a convincing argument – you will in almost every conceivable case have a build pipeline in place anyway, so there's not really a cost there.
I don't set up a "build pipeline" until I'm sure the app is going to deployed to a production environment. Why would I set up a build for what is essentially a fiddle, or if I'm just experimenting? The now-common workflow where people write build scripts at the start of a new project is just bizarre to me.
Is that a major concern? In practice, it's unlikely any serious use of ES6 will run in a browser without a build step due to concatenation, minification etc
Plus, CS just seems like it's always a step ahead of JS. In using it, you can code in a more intelligently designed language that enforces best-practices better than JS does. Doing so supports diversity, innovations (after all, many of these ES6 features are obviously inspired by CS).
Why abandon such a wonderful language when it still has so much to offer, and at the same time seems to be driving innovation in JavaScript itself?
I looked at 6to5 and started re-writing a few files of CoffeeScript in ES6. First impression was not great. I'd forgotten how many curly braces are required in JS. ES6's fat arrow is just not as nice as CoffeeScript's (required parentheses, no option for thin arrow). I'll no doubt try it out again soon, but I'm not a convert yet.
ES6 fat arrow syntax doesn't require parentheses if there is only one function parameter. If there are more, parentheses make the code more readable in my opinion.
If you're accessing objects that deeply, something is breaking the Law of Demeter about locality of reference and looseness of coupling.
It's a syntactic convenience, but it leads to questionable patterns. Do you really want to silently collapse the hierarchy of whatever was null? I'd rather identify it and fail with a specific message or behavior rather than generically.