The first comment actually means a strong opinion. Impossible usually really means impossible from technical standpoint and is not used for things that are heavily inconsiderate or inconveniencing future development. The suggested option is Machiavellian and patronizing at the same time, and pushing burden of proof on the author of the code instead of reviewer. Puts them on defensive. Both are evil, but first is clearly an opinion, second is also a personal attack.

Proper review really must have "X because Y" form with perhaps exception for trivial syntax fixes. Like form 5.

Part two also forces additional burden of proof on the author. Generally for performance changes documentation requirement is the only thing. Preferably runtime numbers or profiles rather than abstract notions. We've seen people going for algorithmic gold plating where it actually list performance to constant factors.

Doing 6 in excess is viewed as patronizing. There is no good way around it.

And finally, presuming you know the teammates making the review as bland as possible without a bit of color can be the worst thing as reviews will be felt as a chore. They are one still but humor can help. Some people like their reviews to be ultimately super boring instead, and you have to be careful.