The whole point of lexical scoping is that code in an inner scope can't mess with an outer scope's variables without meaning to. CoffeeScript doesn't achieve that. The same code in an inner scope means different things depending on whether the outer scope uses the same variable names. It's broken.
Also, using really common identifier names (like "log") in outer scopes is a bad idea regardless of how your language's scoping works. Writing `{log} = Math` at the top of the file is just polluting your namespace for no good reason. You shouldn't do it, just like you shouldn't use `from math import *` in Python.
But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code).
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.
It's not a bug, but it is an unfortunate quirk of the language. But find me a useful language without any unfortunate quirks, and I'll give you some sort of medal.
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.
And my point is that you can't watch out and protect yourself from it, because the quirk can be triggered by different code from the code you're actually writing. You can carefully write code that works just fine, and then, unbeknownst to you, someone else can modify a completely different part of the file, and break your code. How do you protect yourself from that? By making sure that every single person with commit access always follows best practices? Good luck.
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.