Crockford can be an arrogant ass about this stuff, that's why jshint exists, because not agreeing with Crockford does not mean bad JavaScript, no matter what he would have you believe
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.
Arguing about future version of the spec is silly. For all we know the next Javascript spec turns it into a Lisp, and 100% of existing code is broken.
JSMin is breaking working, spec compliant, cross browser compatible code. How is that not broken?
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.