A major problem with any state machine is that they tend to fall apart or become major bottlenecks if concurrency is required... It is still shared state, a thing to minimize. Usually message passing (current buzzword: reactive) approaches work much better.
One of the classic ways of architectural a concurrent system is as a collection of sequential processes implementing message processing loops as state machines.
If you mean that state machines can't deal with internal concurrency, that's not true either. Leaving out concerns about unmanaged state (mutable data not reflected in the state of the machine), a state machine provides a clear framework for managing concurrency:
(1) an unlimited number of events that produce self-transitions can be processed simultaneously;
(2) an event that would be processed the same in the start and end states of all currently running events and whose end state would not alter the processing of any currently running event can be processed concurrently,
(3) an event that would not be valid in the end state of any currently running event is invalid,
(4) any other event cannot be run concurrently, blocks new events entering processing, and must be evaluated for validity after each running event completes (it may become either runnable or invalid).
The last is a kind of bottleneck, but it's usually not introduced by the state machine so much as a feature of the domain.