Good code is self documenting as in you don't need to describe what it is doing and it is clear to read. Whoever says that and isn't just repeating what they heard understands that whenever you are doing something not explicit in the code it should be on a comment.
Workarounds and explaining you need to use this structure instead of another for some reason are clear examples, but business hints are another useful comment. Or sectioning the process (though I prefer descriptive private functions or pragma regions for that).
It also addresses the hint that the code should be readable because you're not going to have comments to explain spaghetti. Just a hint, doesn't prevent it. Others also said it, comments are easier to get outdated as you don't have the compiler to assist. And outdated comments lead to confusion.
I'm with you but sometimes you don't have the chance in low level. Max you can do is create local variables just so the bits you're XORing are more obvious. And whenever you're working with something where that'd be wasteful and the compiler doesn't rid if it, you're better off with comments (which you need to maintain, ugh)