Honestly, modeling state with polymorphism can be really elegant and powerful. There are a few decisions to make (for instance, do States explicitly make transitions happen, or do they return the next state?)
But in general, anywhere you see a lot of conditionals, you probably want to consider a polymorphic approach. Especially if you have more than one function with parallel logic trees.
What do you think of my concern of it "scattering the transition logic" across the classes? Each class becomes a production, and only it knows which classes can come next. It's hard to get an overall grasp of how the state machine works, because you have to inspect all the classes to know the transitions.
This is a significant concern for me when reading others' code: the individual parts might be easy to understand, but there is usually no documentation of the overall design, of how the parts operate together. And there is no code that ties together all the parts - so you are forced to inspect all the local details in order to get a global overall view.
There are many ways to evaluate a program - how efficient it is, how many features it has, how complete it is, whether it is consistent, whether it is correct, how easy it is to prove things about... but I think how much work it is to understand is one of the most important - and usually neglected. For a complex program, having some way to quickly grasp the overall design is key to this, IMHO.
But in general, anywhere you see a lot of conditionals, you probably want to consider a polymorphic approach. Especially if you have more than one function with parallel logic trees.