I would suggest simplifying as much as possible, which will mean more rather than less FSMs in the scene. You can put more than one FSM on a game object, which can reduce clutter in the hierarchy, and for me at least it helps group things logically so I can find them again later. For instance, "go_SpawnManager" could have "FSM_Spawner", "FSM_ClearSpawnPoints" and "FSM_waves" all attached. That way I know everything to do with spawning happens around that one game object.
Generally, each button or button set could have it's own FSM. For instance, an on/off button with two states could really be a four state FSM... one state for each of two GUI Button actions, and one state for each thing that button does, all flowing together in a loop. Setting things up individually will keep you from having cluttery branching stuff to handle all the various cases of things being on or off, etc. Even with only three buttons you would grow to a huge, unmanageable FSM! It may seem like more effort to have multiple FSMs instead of one, but trust me, it really isn't, especially when you are trying to fix bugs near the end of the project!
When a buttons action is simple and unique you can put the functionality in the same FSM, but I generally like to have "managers" that do all the real work, and have the GUI elements just "Send Event" to the manager. That way I can iterate on both throughout the project without breaking either. This approach lets you focus on two separate things... 1- did the event happen, and 2- did the action I want take place? This also lets you call the same action/event from various sources, which becomes really important in most games.
I hope that was helpful!