Does anyone know Rosen's role in Sega Saturn? I owned one and loved it so much. It was ahead of its time, given few mastered its design intricacies while those who did are legendary.
My suggestion would be typical: concise, professional, and when straight-forward, specific. The key is to remember that the nature of a code review is first to improve product, and perhaps secondarily to improve process (ops or procedure) and perhaps thirdly, people improvement in the form of collective learning.
Thus, if we're talking about refactoring a line-of-code then just writing the refactored line-of-code is probably the most clear and concise. If it's more involved than that, then it may be worth taking offline. In the example you've provided here, I'd suggest the best language is likely: Refactoring this block as a separate function provides the following benefits: 1. blah, 2. blah blah, and 3. blah blah blah and no side effects. The only additional clarity that's helpful is to say whether it's optional, required, or some other directive.
Cargo cults concerned me too but I realized that cargo-cult programming flourishes when it's enabled by a culture that doesn't care how the sausage is made. If the culture seeks full stack truth, it's not likely to get fooled by bad generated code, no matter whether it's generated by copy/paste, metaprogramming, or AI.
I'd love to know what Donald Knuth thinks given the history of literate programming.