I do believe that light commenting is good.

In your bullets, you make the following points:

1. helps clarify the problem before coding

   Yes, but sometimes these notes should be kept separate as design documentation. Some of this can also be done by writing tests.

   Here you are saying they have served their purpose already; you need another purpose to shove them into the code.

2. reminds you ... what you thought you were doing.

   This is true, but it is could also true of the code itself. This can also be done with tests.

3. [make] obvious that there's a mismatch between what was intended and what's been written

   No, this is like having two compasses that don't agree. Well, if you're the author, it can work until tickling your memory doesn't help.

   Expressing your intentions for some code can be more precisely done by tests.

4. make you to consider edge conditions and check [them]

   Better done by testing.

5. require you to express and examine assumptions.

   Better done by testing.

6. justify and document the choice of algorithm or method.

   Agreed.

7. leave notes on things which were not obvious when you worked out what needed to be done or how to do it

   What is being done and how it is being done is captured in the code; the mindset of a maintainer with the artifact of the code before him may not mirror that of the writer who sat down with no code in front of him.

8. and so on.

   May your comments not be so vague, :-) and testing will probably help with whatever this is :-).

Be well,
rir