If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE.
Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/...
Enforcing best practices by throwing errors where other languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.
My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.
Please don't say something along the lines of, 'If you hire bad coders, what do you expect to happen?' Bad coders are almost inevitable, and their harm should be confined to code they actually write. Their bad code shouldn't have spooky action at a distance on good code someone else wrote.
Of course you can. You simply enclose the block in an immediate function (using "do") and declare your local variables as parameters to the function. Do that, and it is impossible for any outer scope to screw your code up.
If you're working on a project where lots of coders of questionable aptitude are going to have commit access, you make declaring local variables this way a required convention.
If you're working on a project where changes get approved by a small number of capable maintainers, then you:
1. Do not allow commits that create short or common names (i, x, arr, log, etc.) in high scope levels, and
2. Require that short or common names in inner scopes be declared using local scoping via "do".
Now, should CoffeeScript give some nicer sugar to encourage this kind of local variable use? Yes, probably. But it is incorrect to say that CS doesn't give you the tools to protect yourself from outer scope pollution.