Sure, but then you're missing out on the ability to visualize your states and transitions, much less statically analyze your state machines, generate tests for them, etc. etc.
There's a lot of potential goodness that you lose when you drop down to "normal code" as opposed to a formalized structure.
This is one of the things that is preached pretty often in the Clojure community: it’s all about the data
Describing your application behaviour in data not only allows for all sorts of static analysis (as David mentioned above) but also the ability to change the behaviour without changing code. You could describe multiple different workflows in your application as different state machines, save them to a data store, and load them up dynamically depending on the situation/user.
I’m going off topic, but this approach goes beyond state machines. Focusing on a data driven approach allows you to do some pretty interesting stuff, like designing whole APIs and UIs using data only: https://youtu.be/BNkYYYyfF48
There's a lot of potential goodness that you lose when you drop down to "normal code" as opposed to a formalized structure.