Вариант с состояниями во-первых привычнее и понятнее, потому как отображает привычную диаграмму состояний. Проще использовать, меньше ошибок сделаешь.

Любой другой вариант реализации машины состояний надо обосновать. Может в каком-то конкретном случае удобнее будет сделать как во втором варианте описано. Например, если у нас 2 разных события но 100 состояний с минимальными отличаями, я бы постарался обойтись без 100 подклассов. Но скорее переопределил бы а что у нас состоянием называется.

С обработчиками проблема будет с пониманием "что это такое". Обычно если мы говорим об "event-based" то у нас на каждое событие может быть много обработчиков, никакой определённой очерёдности обработки событий, и по максимум распараллеливание. В вашем варианте у каждого события обработчик один. Если обработчиков много, то как им всем переключать состояние? Тоже событием? Тогда надо как-то синхронизировать очередь сообщений, не выдавать следующие события, пока все обработчики не переключились в нужное состояние, а то один обработчик в состояние Б переключился и уже следующее событие обрабатывает, а второй всё ещё в состоянии А висит. Сломаем весь смысл событий.