とても素敵な切り口で好きです！ 多分表明されていない文脈として存在していると思うのですが「レビューによって育てる」という目線が強くなっていると感じました。
私はプログラマのトレーニングを生業としつつ、受託の開発にも参加しています。トレーニングは「現役のプロが全てのコードをレビューする」という触れ込みなのでレビューしまくる形になります。受託現場でもコードを書くよりもレビューする立場にあることは多いです（たまにそれがストレスになるくらいです。もっと私にコード書かせて！w）。
同じ私個人ですが、実は上記の二つのパターンでレビューの仕方、アプローチは異なります。
トレーニングの場合（育てたい）
- 問いかけが中心。
- 直して欲しい場合には勿論、正しい場合にも理解の確認をする為に問いかけることがある。
- 考えてもらうきっかけを作ることをレビューの中で意識している。座学で教えらえるのではなくて生の学び。
受託の場合（バランスよく進めたい）
- 指摘が中心。
- 今の締め切り感などと合わせて指摘の深さが変わる（「まぁ、いっか」の程度が違う）。レビューの為に開発者が進捗遅延のストレスを感じないようにしたい。
- こちらが「どうして欲しいか（直して欲しいのか、意見を求めてるのかなど）」を明確に示すことを意識している。曖昧だとレビューの突き返し回数を増やしてしまう。
- 最近は場合によって「提案PR」をすることもある。コードで示す方が早い時もよくあるので。
共通
- 相手にあまり冷たく見えるような表現は避けています。文意は明瞭でも、表現方法はある程度考慮します。
- 「xxxしてください」よりも「xxxにしましょう」的な表現が多い気がします。
- その為もあって「どうしてもここは大事」というところはあえて無感情な指摘の仕方にすることがあります。
- 罵倒・嘲笑などはもってのほか（なんか世間にはそういうレビューする人もいる様子なので念のため）。
余談ですが
プログラマにとって、コードレビューの学びの効果は絶大だと思っています。コード品質を上げながら同時にメンバーを成長させることができるとすれば、長期目線だとコードレビューの費用対効果はすこぶる高いのではないでしょうか。
たまにまだこれからなチーム/プロジェクトのコードを見せていただくこともありますが、そういう場合はメンバーに安心感も与えることができるようです。そういう意味でも先達にコードを見てもらえることは大事にした方が良いと思います。もしも見てもらえる人いないチームがあったら、弊社なら声かけもらえれば何かお役に立てるかもしれません（と、ちょっと宣伝）。
