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.
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.