"Change 'this' to 'that'" is much harsher than "Could you change 'this' to 'that'?"
It's a small change in wording, but it changes the interpretation from "This is wrong, do this instead, I know better than you" to "I think this is a better way to do it".
Especially rewording change requests as questions is something I don't like. Is this something that should be done? Is it just a question about the technical possibility? A request for comments about the intended change? (I've seen them all and the more friendly they are worded, the harder they are to tell apart)
I can find instructions disguised as questions condescending, for example.
I believe no amount of wording will help if people are not trusting each other. I would rather work on team building than comment guidelines.
I mean sure, in some cases you can completely disassociate from the human side of code, disregard a comment's name in favor of objective truth or however you want to word it, but in a lot of instances you still have to share the same office with that person.
In other teams, a comment like this would have meant a chat with HR. We can't make rules for these things, because people and thus teams are different.
Rather than forcing people to exercise self-discipline while reading, it's nicer to exercise it yourself, and write comments in an impersonal way. Assuming that the reader is as smart as yourself just follows logically from the idea of peer review.
This is what I got from about 10 years of doing code reviews, which sometimes needed to be scathing by nature; to induce the desirable changes you've got to genuinely sound like you're acting in the author's best interests, not just do so.
And then there's things that I would like to see changed, but as a personal preference; when it comes down to it, it doesn't make a difference and I don't really care, so I would posit it as a suggestion instead of a command. Mind you, if I didn't really care either way, I could've chosen to ignore it as well. But you know how some people get <_<
Asking also seems dishonest if I'm not truly inviting a discussion.
I think it's really worth emphasising this. Further: If the reviewee understands that feedback can be discussed, then the reviewee can discuss whether they're asked or told. If the reviewer has more authority than reviewee, then asking really ought to be asking a question.
...then everybody is stepping on egg shells.
I think the intention behind rephrasing from "this is wrong" to "can it be this instead?" is to try and take the ego out of it. Except people are complicated and 'taking the ego out of it' isn't just down to a question of phrasing.
The reason code reviews are done is to try to catch mistakes earlier. (Mistakes are more expensive to once more development has been done on a task). I like the term "psychological safety". It strikes me as 'unsafe' if a review comments are a matter of the reviewer's ego over the reviewee's. It should be fine to make mistakes, and to have those mistakes corrected. Because people are complicated and emotional.
Also, sometimes the answer won't be the one you'd expected.
It seems these practices are created because people are using reviews as some form of conversation, and then everybody is stepping on egg shells. I believe if the entire team agrees to see it as just annotations (it's not a performance evaluation, leave your ego at the door, etc) these problems are avoided.
(I can see "why" you need these guidelines though, I guess it depends on what kind of work culture you have, company size, and so on.)