Well, if your states are modifying game properties, it’s easier and more efficient to just save and restore those properties directly, isn’t it? 
Re-triggering states might work in some narrow cases, but it’s not a general solution, since the path to a state is not generally unique. You cannot observe the machine’s current state and infer how it got there, except in very limited cases (e.g., each state has one parent and the FSM is acyclic). And there are plenty of situations where re-triggering each parent state produces incorrect results, too. Plus, if your states are doing performance-hungry things on entry/exit, like loading/unloading sublevels, it’s really not a good idea to force the game to do an entire sequence of those tasks if it only needs the last one.