что привычную - это ясно. насчет 100 состояний - то это как с таблицей. здесь естественно читать таблицу с тремя колонками и 100 строками, чем наоборот. но с таблицей все зависит от конкретностей скорее, чем от привычек.

что касается "переключился-не успел переключиться", то объект у нас - один, и обрабатывает все сообщения, выбирая их из одной очереди. выбрал сообщение - вызвал обработчик соотв. типа. сообщив ему текущее состояние. обработчик обработал сообщение и вернул новое состояние (возможно, то же самое). фактически вся кухня закручена для того, чтобы при поступлении сообщения (наступления события. но не путать с другими patterns, где на одно событие может быть множество подписчиков! возможно, безусловно, на одно и то же сообщение/событие реагировать нескольким state machine, но мы не об этом) его обработал какой-то метод, предназначенный для обработки данного сообщения в данном состоянии. в принципе, можно это в двух вложенных switch конструкциях обработать. принципиальной разницы, какой свитч будет внешним, какой внутренним, нет. можем, в принципе, увеличить "мерность" этого пэттерна, добавив еще что-нибудь. день недели например. извините, в вашем посте я не увидел других весомых аргументов, кроме "отображает привычную диаграмму состояний". это, конечно, аргумент, но неочевидно, почему "Проще использовать, меньше ошибок сделаешь.". привычнешь за пять минут, и будет так же удобно, как и раньше.

представьте себе сравнительную таблицу параметров какого-нибудь продукта. количество параметров и продуктов примерно одинаково. скажем, десяток. приходилось видеть и строка==продукт, и строка==параметр. никакого привыкания, оба варианта подходят. лишь бы продукты и параметры были выбраны правильно : )