It's up to you whether to create or participate in polls. Although I've never promised to strictly obey the results of every poll, I value their results and give them a heavy weighting in decisions.
Why should we vote then if your vote is the "strongest" ? I don't have problem with you commanding, but please state that loud, so we don't live in imaginary world.
Although it's currently up to me to decide what goes into the autohotkey.com version of AutoHotkey (at least until others join the staff), anyone is free to create and distribute a version of AutoHotkey that has the features they want. Alternatively, one could make a preprocessor script that translates syntax they like into AHK-compatible syntax (this has been done at least once).
I think it is a question of degree: commands like SetKeyDelay -1 are global settings that can be detected and changed by the script while it's running. But directives are "worse" because they alter the behavior of the entire script and its include files.
I don't see this as an valid reason. There are already number of colaboration breaking directives and NoEnv is not the only one.
Coordmode, SetKeyDelay, SetFormat etc.. will all change scripts behavior if not specified so regarding to this new directive will not spoil collaboration as it is already not possible for sure.
As I said, I expect that #NoEnv will be made obsolete in v2.
People get used to NoEnv witch introduced the very same type of problem.
Although a directive such as #TreatEmptyAsZero wouldn't "spoil" the language, its presence in the documentation would make AutoHotkey seem more complex, especially to new users. But that is a small drawback compared to the fact that it comes close to splitting AutoHotkey into two separate languages.
This thing is optional and as such can not spoil the languages as it adds new functionality as needed. People that don't want to use it can skip it or even not know for its existance.
Other than #NoEnv, I don't think any of the other language-altering directives are commonly used (such as #EscapeChar). I want to avoid adding any more of them except those that directly help debugging like #MustDeclareVars and #ShowWarnings.
THE POINT: New directive can not spoil something that is already spoiled.