When JSLint hurts your feelings, hug it out with Doug.

1. There are some situations that are difficult to distinguish mechanically, so I now consider all of those cases problematic, even when they are not obviously wrong.
2. You should be coding for readability and error resistance.
3. The place to express yourself in programming is in the quality of your ideas, and the efficiency of execution. The role of style is the same as in literature. A great writer doesn't express himself by putting the spaces before his commas instead of after, or by putting extra spaces inside his parentheses.
4. Many people think they have good reasons for doing things badly.
5. The purpose of JSLint is not to make you feel good about inadequate coding standards.
6. You are presuming the whitespace at the end of a line is either trivial or harmless. ~Austin Cheney
7. JSLint is not able to determine which cases are troublesome and which are useful, so it warns on all cases.
8. It is easy.
9. It seems like good advice.
10. With respect to spaces at the end of lines: From a code hygiene perspective, there is no good argument for keeping them. If you are arguing that there is no one in your organization with the programming skill to remove them, then it seems your organization is suffering from problems that JSLint cannot help you solve.
11. If you have a Java mentality, they might be useful. I have a JavaScript mentality.
12. It is much harder to write correct programs if you do not understand what the language actually does.

If you can’t read a program and be confident that you know what it is going to do, you can’t have confidence that it is going to work correctly.

Features that are both dangerous and unnecessary should to be used at all.

@ericnormand reminds me of my favorite line from JavaScript: the Good Parts (emphasis mine)

…avoid features that are often useful but occasionally hazardous. Such features are attractive nuisances.

I love this concept of attractive nuisances. Imho it is a metaphor that explains so much about what can go wrong when architecting a system :)

@hickerm it's really interesting how often readability comes up in the literature of software systems safety. For instance "comprehensibility and readability of code" comes up again and again in Gerard Holzmann's research on software safety at JPL/NASA. In "Powers of Ten" (PDF) he goes so far as to discourage basic practices like recursion, on the grounds that although recursion is useful in many contexts…

Without recursion… we are guaranteed to have an acyclic function call graph, which can be exploited by code analyzers, and can directly help to prove that all executions that should be bounded are in fact bounded…

Sounds eerily similar to Crockford's caution against "attractive nuisances" and the other passage pointed out by @ericnormand. I think there may be a common theme here: give up something useful in order to make static analysis easier, and the overall win may be large (at least when wins are measured in terms of overall system safety and reliability in the mid-to-long term).