表2（脆弱性1を確認した手順）の項番3の攻撃が成功するのは、taikai_tokenが送信されなかった場合、hiddenフィールドとの比較が上手くできないという、プログラミング実装上の不備があるからという理解で合っていますか？
また、同表の項番5の攻撃が成功しないのは、hiddenフィールドの値が確認できないから、ということでしょうか？

>taikai_tokenが送信されなかった場合、hiddenフィールドとの比較が上手くできない
hiddenフィールドとの比較をしないで通してしまう。（不備）
だと思いました。
>項番5の攻撃が成功しないのは、・・・
confirm（え） → submit（お）  でないと通らないのではないかと思います。

回答ありがとうございます。
単にhiddenフィールドとtaikai_tokenの比較ができていない不備だったなら、なぜ項番5の攻撃が失敗するのかがわかりません。比較ができていないのなら、項番5の場合も成功してしまいそうな気がするのですが。

比較対象の認識に誤りがあるようです。
（お）で比較されるのは
・POSTデータ内のtaikai_token
・セッションオブジェクト内のtaikai_token
です。hiddenフィールドではないです。

taikai_tokenは（え）の処理中に生成されます。
この時、
・hiddenフィールド
・セッションオブジェクト
両方にtaikai_tokenが格納されます。
hiddenフィールドのtaikai_tokenは「退会ボタン」を押したときに
POSTデータのtaikai_tokenに変換されPOSTされ、（お）に遷移します。

項番５の攻撃が失敗する理由ですが、
（お）の処理の際にセッションオブジェクトにtaikai_tokenがない場合は
その時点でエラーとなる作りと考えられます。

項番３の攻撃が成功する理由ですが、
（お）の処理の際にPOSTデータのtaikai_tokenのチェックが甘いと考えられます。
taikai_tokenが存在しなくても、セッションオブジェクトにtaikai_tokenが
存在してさえいれば比較処理が成功してしまうというバグを含んでいると
考えられます。
この点をCSRF攻撃で突かれたというのが本問のシナリオになると思われます。

納得がいきました！丁寧な解説ありがとうございます。