気持ち
ReactのComponentは、stateが更新されるとコンポーネントが丸っと再描画されます。このとき、Virtual DOMのおかげで差分のみがDOMに反映されるので、性能をそんなに劣化させる事なくUI制御をすることが可能になります。
でも、アプリで表示するデータがFBのタイムラインみたいに無限に取得できるような画面の場合、いくらVirtual DOMといえどもさすがに辛いのでは。さらに、もしそのデータがネストしていたら、実際に描画しないとしてもネスト部分のループ処理は行われるわけだよね？実際どうなの？
調べてみた
ということで、jsperfで実際にやってみました。
[
{
id: 1,
firstName: 'xxx',
lastName: 'XXX',
children: [...]
},
...
]
という感じのネストしたデータを大量に表示するコンポーネントを二つ用意し、一つは何も考えずにコンポーネントを定義、もう一つはshouldComponentUpdateを使って、childrenの配列に変化がなければ（つまり !== で比較してfalseであれば）childデータの表示コンポーネントは再描画しない、というようにしています。
shouldComponentUpdateは、コンポーネントを再描画するかどうかを決定するAPIで、defaultは常にtrueを返す、つまり常に再描画するようになっています。
https://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate
結果はこちら
http://jsperf.com/react-performance-shouldcomponentupdate
（表示が重いのでブラウザ一瞬固まるかも。固まってもそっとしといて）
root2のほうがshouldComponentUpdateを使った結果ですが、結果は明白ですね。
1秒間に10回再描画処理（実際には何もしてない）が走るのに対し、shouldComponentUpdateを使わない方は1秒間に1回の描画すらできていません。
とはいえ
shouldComponentUpdateを使うと、コンポーネントのメンテナンスコストも上がりますし、この差分チェックロジックにバグがあれば意図した通りにUIが反映されない、という辛いバグにぶつかるかもしれません。今回の例だと、dataコンポーネントの表示全体としては問題ないけど、なぜかchildlenデータ部分の表示だけおかしい、みたいなことが起きるかもしれません。FBが推奨するようにimmutable-jsとPureRenderMixinを組み合わることを考えた方が良いかも。
まとめ
性能面が問題になるくらいに複雑なデータを表示しないのであればこのAPIを使う必要はなさそうですが、万が一性能が問題になった時はshouldComponentUpdateで回避できることを思い出そう。