何故なら組み合わせ爆発が起こって訳の分からんクラスが山のように出来る可能性が高いからだ
普通に考えても、状態チェックして例外投げるなりエラー返すなりassertするなりするより、手間がかかるからだ

ある状態の時、あるメソッドを無効化することを考える
状態をチェックして無効であることをプログラマに教えるコードを仕込む・・・①
状態に対応するインターフェースを定義して実装する・・・②
この時、ただでさえ①より②の方が手間がかかりそうなのに
これに加えて状態の組み合わせ爆発で訳の分からんクラスを大量生産する羽目になったら
何をしているのかもはやよくわからない

また、状態が変化してインターフェースAからインターフェースBへはどのように移行するのか
ここで、誰が移行させるのかは問わないが
今まさにインターフェースAからインターフェースBへ移行したとして
B b = nanika( a );
まだインターフェースAの変数aは生きているので
(しかも、どこでだれが、どれだけ握っているかは分からない)
状態にそぐわないメソッドを呼ぼうと思えば呼べるわけで
結局エラー処理は(するなら)必要だ、意味がない

もしくは、B b = nanika( a );を呼び出した瞬間から、aのオブジェクトを無効にしてしまう
aのコピーを作ってそれをBを満たす状態で返し、aは無効フラグを立てて、意味のないオブジェクトとする
以降aのメソッド呼び出しは全部無効
しかし、あちこちでaが握られていた場合、aが無効になってbになったことをどうやって各所に通達する？

このようなことを考えていくと、とても現実的じゃないんだわ
まぁうまくいく場合もあるかもだが、かなり限定的だ
そもそも手続き型言語は状態や順番やタイミングによって、呼んで良かったり、ダメだったり
正しく動いたり、動かなかったり、正常だったりバグったり、するものだから
根本的に解決したければ関数型言語でも使ってもらうしかないんだろう
手続き型言語で手続きそのものの誤りをコンパイラに検出させようってのは、かなり、なんというか
プログラムの並びが正しいかどうかコンパイラに調べさせる話だから、それ出来るならすごいよね～