Jacob ("fat") comes off looking far worse than Crockford, to my eyes (and that Kit character seems to be 7 years old). It's the arrogance and stupidity of youth facing the crotchety crankiness of experience. Crockford has earned the right to have a strong opinion here IMO.
I have never written a line of JS in my life, which hopefully qualifies me as an unbiased outsider, but I don't agree that that Crockford's position here on JSMin is the right thing to do.
Here is what I see:
@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.
The fact is that @fat's code is legal code and JSMin is breaking it.
IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".
Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.
Language lawyering is fine and dandy when you know exactly which compiler will be used and you know exactly how it works.
But on the web that isn't the case. You can write code, but you have no control over what browsers, past, present and future, it will get run on. And it is your responsibility to make that work. According to the spec, you may be right. But in practice you're the one who is wrong, because you're the one whose job it is to make your code work across browsers and future versions of the spec.
That said, it's hard to program to a spec that does not (officially) exist yet, and doubly so if there's not clear "opt-in/out" path for future versions. Since, as a developer, I can't control what the committee adds or removes from the spec, or what they might break, I can only do the best I can with the language as it is -- not breaking existing code in future versions of the language is the committee's job.
No one ever earns the right to be a jerk. Crockford can have a strong opinion all he wants, but if he wants people to continue looking up to him, he will explain and conduct himself in a civil and professional manner.
No one won in this situation, but Crockford should know better by now.
I'm uninterested in any specifics, actually; I'm more interested in how much of the syntax landscape is cut off for future extension, particularly at the expression level.
It's one thing to insert semicolons in this case:
<ident> <op> <ident> <op> <ident>
and another to do so in this kind of case:
<ident> <op> <ident>
The former is unlikely to be problematic for future extension, but the latter more so. The general pattern in Algol-derived languages is for all statements (except for expressions, including assignments and procedure calls) to begin with a keyword. This substantially reduces ambiguity - semicolons are mostly redundant in this situation - and it seems to me to be a fine place in JS to automatically insert them.
Another distinctive feature of Algol-derived languages is that two adjacent expressions are generally not meaningful; for example, <ident> <ident> is not usually a valid expression sequence in Pascal, C, etc. (and in the presence of typedefs, it is actually a concrete problem when trying to parse C declarations, often requiring communication between lexer and parser to turn typedef identifiers into keywords for the purpose of parsing). This in turn creates freedom for creating new keywords unambiguously, by including whitespace in the "keyword" (actually two words). But JS foregoes some of this, because <ident> \n <ident> will have a semicolon inserted on the line break. It's not too bad though, because new two-word "keywords" are not usually broken over two lines; but long expressions almost always extend over multiple lines at some point.
The 'latest revision of the future specification' you link to is, I think, the set of things the TC39 group has considered and agreed on. The list of things they are currently considering is in the strawman namespace on that wiki. In particular, the "strawman:concurrency" page currently says:
The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.