A developer I used to know put it thus: "A comment is an apology." I never asked him to explain that, but I guess he meant it's an apology that the code itself is not self-explanatory.

Clear, even verbose commentary can be helpful. But where it often breaks down is when the code is revisited, and the comments are not updated as well. So my practice now is to use comments in early development to help me remember what I was thinking in that bit of code, but then remove most of them during clean-up and refactoring unless something particularly non-obvious is going on. It makes future maintenance of the code less likely to diverge from the (usually unmaintained) comments.

Good code review could help here: "Hey, the diff shows you changed six lines of code in that function but the comments are the same, do they need to be revised?" But I've never worked anywhere where EVERY commit was reviewed, rather a sampling is selected for weekly review. that leaves a lot of opportunity for things to get missed.

Bottom line: extensive comments can add to workload when fixing bugs or making enhancements. So only use them when they really count.