To answer your title, if not your article, no, state machines aren't used just to parse stuff.
About ten years ago I rewrote the communications layer for a pharmacy management system that was used in about 900 stores in Ontario. Because the system could be used with either a dial modem or a 3201 (poll select) device, I needed to have a state machine that was configurable at run-time, based on the current configuration. Thus, if the 3201 service went down (it did occasionally), a store owner could be talked through changing the configuration, restarting the communications layer and getting back on-line to filing on-line health claims. There were also stores in Northern Ontario that didn't have 3201 service and were permanently on dial modem connections.
The differences were that the modem had more states: it had to dial a number, check that it got CONNECT back, send the transaction, get a response, try again if the timeout was exceeded (and possibly do this for multiple transactions), then break the connection. The 3201 device was always connected, so it just had to send the transaction and get a response.
I used a state machine to take care of all this -- an array of function pointers (this was a C program). Depending on what mode it was in, and what the exit state of the previouis step was, the machine could determine where to go next (and what to do). It worked just fine.
And the same executable also ran as either a TSR or as a separate task under PC-MOS -- that was a fun piece of code to write.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds