No thanks.

If the internal state is compromised yes. However, you want to reject the bad actor's input before that happens. Parsing things with state machines and related automata, and cleanly rejecting invalid input (and dispensing with associated state) is not rocket science. (Note that method calls related to some piece of state can be viewed as inputs/transitions on an automaton).

Asserting and crashing should be a last resort in daemons that must provide shared-state services to multiple actors. While it is preferable to assert than to allow a security critical error, asserting itself may be a security critical error - handling errors cleanly is again preferable to the assert. A better approach is to have multiple layers of defence, with asserts against critical inconsistency errors at lower layers (e.g. forcing all IO through checked, bounded buffer abstractions), and well-defined automata at higher layers to provide clean error semantics (potentially multiple levels of such). You can't just restart, because of the shared-state. If you externalise the shared-state so that the code can be restarted, you still need to ensure that shared-state can never be manipulated into an inconsistent state.

All the world is a state machine, even the functional programming world. ;)