プランナが仕様を切ってそれをプログラマが実装する、というのは、
単なる役割であって、地位が高いとか低いとかって話じゃないよね。
>>880の会社は単にプランナが仕事してないだけって気がする。

というか、例が下手なせいで話がずれてるが、プログラマの地位（というか
発言力？）の高さと、「仕様変更」が発生するかどうかは関係ないと思うが。
元仕様の不備だろうが、実際に動かしてみて生じた新しいアイディアだろうが、
ゲーム製作において（まともな）仕様変更は普通にあり得るし、それを
「そういう作りじゃないので変更は出来ません」と突っぱねるわけには行かないわけで。

で、その仕様変更に対してタスクシステムが有用かどうかということだけど……。
俺の経験上、同じような変更であっても、多少、修正する箇所が少なくて済むような気が
するけど、「仕様変更に備えるためにタスクシステムを使う」というほどの差はないと思う。
どんな方法だろうと、大抵の記述はオブジェクトやシーン単位で完結してるし。

>>875
この場合YAGNIは的外れじゃないか？
タスクシステム（>>2だろうがそれの発展系だろうが）を使って組んでいるなら、
既にタスク周りのコードは組みあがっているわけで、依存関係やバグが増えることはないよ。
タスク処理そのものを新しく作るとしても、初期仕様からそれを利用するわけだし。