http://blog.nodejitsu.com/scaling-isomorphic-javascript-code
"Javascript is now an isomorphic language. By isomorphic we mean that any given line of code (with notable exceptions) can execute both on the client and the server. On the surface this seemingly innocuous property creates a number of challenges that are not solved by current MVC-based patterns. (...) In conclusion, we will explore a new pattern: Resource-View-Presenter."
Except I call my presenter layer "resources" and my resources "models".
The state machine in my framework is a system within the view layer so you can asynchronously re-route through the "presenter" and re-use code.
Any exception on the way rollbacks the whole state, and we commit only when we reach next interaction node.
It works great.
The interface the client uses is always going to be some sort of state transfer system, moving between different pieces of content and displaying elements to transfer between content.
Handling these views on the back end is an entirely different issue.
State machines are useful on the back end, but it can not be used between requests without causing headaches.
I have been experimenting with state machines in a node.js framework to handle asynchronous sub-views (https://github.com/Dashron/roads). It makes development incredibly simple, and breaks up the code so that you can have traditional, or single page apps with the same codebase.
I don't think a state machine would be useful at a higher level than this (in the backend) but I will put more thought into it.