I agree with you point in some cases and not others. I would characterize my position that you should comment just enough that someone other than you (or your distant, future self) and understand what the goal is; why being more important than what, what being more important than how.

If you're working with a relatively simple application where the information the application deals with is conceptually simple: you're absolutely right, explaining what and then having code that has a finite set of possible intents would just be wordy. On the other hand, I gave an example of ERP system inventory costing algorithms in another answer in this general thread where the complexity is different: cost can mean different things under different circumstances and different processes. We try to generalize these algorithms into lower lever functions, but you have to understand the what to know how it's appropriate to use the function... or if it is actually achieving it's goal: it may be coded in a way to be valid in all but the use cases targeted. There simply is no one size fits all answer to how to appropriately comment code (or if to do it at all).

As for bad comments and comment rot... any code, commented or not, can be written poorly or not maintained properly. Yes it's an extra moving part, and if you're not going to be as diligent about documentation as the code then, yes, often times your better without it. I think, however, it's better to force the issue. I don't think you need freestanding documents but by god if you have comments and I see code in a code review where the comments have been neglected: reject that submission.