Sure; but you can handle that as we do in other programs: if it makes sense to do so, make a single method responsible for modifying a state variable and call that instead of assigning directly. And that can manage side effects. Alternately, trigger other changes off the state variable changing using svelte’s reactive code blocks. This style of programming can scale up and down in complexity like any other code you write, and you can scope it and refactor it along with everything else.
What is your argument here? That we already work with state machines implicitly in UI code so there's no point in making it explicit with a library? That Svelte's reactive mechanics are so good that it doesn't make sense to use an external library even if it is specialized for modelling things as a state machine?
Because I agree with you that Svelte is great and reactive programming is powerful but if you had a problem that looked and acted like a state machine, why you wouldn't just use a state machine? And if someone had a library ready to go that managed it for you, so much the better.
