I've been doing full time Coffeescript front end dev for about a year and a half on a moderately complex one page app. I would be happy to never write vanilla javascript again.
The value of coffeescript is that when written well you can get a very high signal to noise ratio in your codebase. When I say "noise", I'm referring to low value syntax and boilerplate, things like:
var someFunc, _this;
_this = this;
someFunc = function(){
return _this.foo;
}
By comparison, the coffeescript is:
someFunc = => @.foo
In the coffeescript example, it is immediately obvious what 'someFunc' does. A trained javascript developer will be good at filtering the junk, and extracting the bits that are actually meaningful and important. But any time you are parsing through a bunch of junk to get to the meaningful stuff, you are opening the door to make mistakes, and increasing the time it takes to comprehend/load the code into your brain.
Another important benefit of readable & concise code is that you can hold more of it on a screen at a time, which makes it easier to keep a full class in context and/or work on a small screen (e.g. laptop on the go). I would much rather work with a 100 line coffeescript file than a 300 line javascript file.
This is the same reason I really love the underscore library (not coincidentally also an Ashkenas product). Everything it does is something any competent JS developer can do. But it does it in one line, and in a way that is very easy to read.
Incidentally, using a library like underscore with good iterators also avoids a common class of the "variable capturing" problem, as you don't end up using named variables for iteration (opting instead for map/reduce/find/etc). We otherwise use descriptive names in our project, so the chance of a clash is minimal. In my year and a half on the project, I've yet to run into a "variable capturing" bug. Admittedly that does mean that when it finally happens, I probably won't be looking for it.