Pretty much all non-trivial objects (composites, or ones with implicit constraints on fields that can't be expressed in the type system or language) have an FSM, at a minimum the 2-state FSM of "Internal state is consistent" and "Internal state is not consistent". You have to deal with that reality one way or another. Tracking that consistency internally through an explicit FSM is one way. Dealing with invalid use of that object after errors through an idempotent error state or assertions or exceptions all have their pros and cons.
You don't have to synchronise all the FSMs. Or at least, if you do, then it wasn't because you added an explicit FSM - you had to effectively be synchronising their state already anyway. All it does is crystalise and making explicit (inc making it queryable to outside users) requirements that are already there.