Too many comments explain what is going on. That should be obvious from well-written code. But comments why it's done that way can be extremely valuable.
And sometimes there is indeed something wrong with the code. In those cases, a comment saying so can save a lot of time analyzing what's wrong with the code.
The counter-argument I've heard is that commit messages are a better tool for those kinds of annotations, especially if there are multiple points across the codebase where a change was made for the same reason.
That's exactly what commit messages are designed to do, too.
I've seen plenty of comments in code that say "handle case X because of behavior in place Y", that's tied to changes in place Y. I find it more meaningful when I see all those changes together, bundled in a commit diff, with a message on why.
In an especially good editor you can even have the title of the commit rendered into the blank space on the end of the line, which I find useful if I'm trying to figure out the past motivation behind a piece of code.
That's a false dichotomy. You can do both. The problem with relying only on commit messages, is that someone examining the code does not see it. You need to dig through the history. People don't do that nearly as often as reading the code.
But if you leave a comment with what the issue is, and add a reference to the commit message, you've got the best of both worlds.
Sometimes context should really be next to the code it applies to. If I'm adding pull-to-refresh functionality I might have a commit with ten changed files; there's no reason to put "use a dispatch_async to the main queue here so the animation gets put on the next runloop" in the commit message.
I came to write basically this exact thing FWIW. Always write the why, not the what. It's the clear difference between useful comments and excess noise.
There are particularly clever one liners that need a bit of unpacking on the what - Python is bad for this but anytime you are patting yourself on the back for the cleverness, a brief note (at least on the test) is probably warrented. I supposed one can code without cleverness but it's less fun :)
Cleverness that hurts readability is not good. Sometimes you can do a lot in a single line without hurting readability (it may even be more readable), but sometimes there's indeed so much to unpack that it's better to show the steps.
And sometimes there is indeed something wrong with the code. In those cases, a comment saying so can save a lot of time analyzing what's wrong with the code.