No substitute for good judgment
Hi, Andrew. Long time, no see. :)
Generally, I think your sentiments are well-reasoned. I tend to favor a standard that relies on good judgment--before adding a comment, ask yourself, "does this make my code easier to understand?" If not, the comment is probably unnecessary and likely harmful.
If the answer is "no," then ask yourself, "what is necessary to make my code easier to understand?" If the answer is "I should probably rewrite this," then rewrite it! If you don't have time to rewrite, at least add a to-do comment saying "this code sucks, rewrite it."
This answers the question of whether to comment. On how to comment -- a project's lead developer should establish an explicit, but reasonable, standard. The team should then stick to that standard.
A Java idea--the javadoc API supports extensions, so you can define project-specific tags if you feel that's worth the effort. In addition, some IDEs (eg JBuilder) recognize the @todo tag and automatically construct task lists for you. This is a huge time-saver for those who have the IDE, and it still helps out those who don't (eg, "grep @todo Blah.java"). Otherwise, "XXX" or some other reasonable header is a great idea, and I've used that extensively in the past.