The essence of the advice is to write code for both the compiler and for people, and to not explain things that are expressed by the code.
Redundancy between the code and comments creates problems. When the two disagree, both are probably wrong. If you have to write it twice and read it twice, someone probably paid for it twice.
Among the answers, we have down votes for explaining how, and up votes for explaining what and why. I agree. Where comments that relate parts of the code, or perhaps explain rationale that can be used to make minimal, cohesive, and coherent classes would be a benefit. The who and when of code can be found in the source control system. Source control commit comments give us an understanding and correlation of the systems evolution toward its goals. Linked with a bug tracker can answer many why questions.
Scope and applicability are good topics for comments. If we are separating concerns the way we should, we should use naming and comments to guide future maintainers. Programming by contract, using assertions, and unit tests are all in the mix of clarifying the meaning and expected behavior of our software.