I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.
I'm neutral about state machines. Obviously in things like microcontrollers and HDL, state machines are really necessary. Outside of those two examples, state machines can either make code much more stable or just add unnecessary overhead with all the wasted cycles. They definitely have their place but there are better options available sometimes like threading a process. I had a project recently where we needed to build a custom message broker. A teammate wrote the entire thing in python as one big state machine. Everytime we needed to add another queue, it involved adding so much extra code to handle it. Another teammate suggested just having everything threaded so we reduce our code down to a template queue and can dynamically create them as needed. The state machine might have been more efficient memory-wise if we were doing it all in C on a PIC or more conservative in PLU usage if it was an FPGA but we were using python on a raspberry pi. We ended up with a broker that could handle more bandwidth in terms of how many queues we could publish to and consume from.
Obviously we didn't really shrug off state machines. We just created many smaller ones (two states: wait for message, push message) rather than a huge one. I think the massive state machines we learn about in our freshman classes are unnecessary in many cases. Memory is so cheap that its not always worth it to be so conservative/old school.
We could have just used something like rabbitmq but we didn't want the extra overhead of a service like that when we had so much more resource heavy stuff running on the pi.
Personally I'm a fan of the smaller state machines you describe. You still got to deal with synchronizing them, but it just seems easier to grasp for me.
Essentially since Bluespec's model is a set of conditional transactions on your state, you can write an imperative sequence of transactions with a few basic flow control primitives (if-else blocks, while loops etc.), and it creates the state logic automatically.
Unfortunately it didn't seem to have received much attention, and I ran into quite a few problems when I tried to use it for anything serious (including one straight up behavioural bug).