> Isn't it useful for the tool to warn about something that is often incorrect but sometimes intentional?

Only if the total number of warnings across your entire codebase is tiny - 10 is the [arbitrary] number I like to use. That is 10 warnings, it doesn't matter if you are writing 5 lines of hello world or a 100 million lines of a self driving car. When the number of ignored warnings get above that number people start to ignore the tool and then it becomes useless.

Your comment drives the discussion in a rather circular fashion: your objection is addressed by code comments that selectively disable warnings at specific locations in code, which is the subject of the original article. So long as you make careful use of those then it doesn't matter if you have 10,000 of them in your 100 million lines of code; you still only get one (visible) warning if you make a change that triggers it again, which is below your 10 warnings threshold.

You need to regularly audit all your warnings with ever tool upgrade to make sure they still apply. Auditing 10000 issues is too hard, so people will soon not be careful. When there are 10 you can check each quickly enough and ensure they are still valid.

With 10000 warnings that means that people have gotten in the habit of disabling warnings, so how many of them are real. I've tracked production bugs to someone disabling a warning - we regularly disabled that warning for correct reasons, but in the one case it wasn't a false warning.

Thus your disabled warning levels need to be small. Small is somewhat arbitrary, but it needs to be small enough that when the tool says something is wrong you trust it.

At that point, why not just make them errors? Making them warnings just makes it easier to put off the decision about whether to disable the rule for a specific case.