You left out one of my favorite pet peeves about reformatting comments in another's code: patches.
If you're working on some code and submit a patch that improves something, that's great. If you submit a patch that makes a one-line code fix and the patch is 50 lines long, that's a pain.
Guess what one of the primary, if seldom mentioned, rules of submitting patches to a project is? Make things easy on the lead maintainer. If a project has 20 files, and your patch makes someone undo 49 lines of comment changes in one file to ensure that the comments match the other 19 files, that's more work than is necessary, and your patch is likely to go to /dev/null. Yes, the maintainer could take the time to figure out where the one meaningful change is, but so could the author of the patch.
Even in source control within a team, if your store is patch-based then you're making a mess of revisions by fighting over comment style. If it's not patch based, you could still be making extra check-ins that are unnecessary and screwing up consistency between files.