No it would be a much cleaner and better UX
As of writing (v3.x, v4.x): If you click to disable debug, server side stops sending messages (to all open clients). If you look at the the 2nd browser, the debug is enabled - but no messages are arriving. If I deploy the first, the 2nd does not know or reflect this change and you would be unaware there was a change until you deploy on the 2nd - at which time you are warned about needing to merge. In effect, by having the state in a server side store, anyone refreshing (or deploying) would not get a merge conflict and would (ideally) just get back the updated state. In an ideal world, the state change would actually be transmitted to open editors (meaning they could reflect the users choice - all without ever having to deal with the dreaded "merge"). In fact, a deploy is already communicated to all open editors today (you get a 5sec toast about changes been made) however you have to catch that, review it/merge it, refresh the page (potentially losing local changes) or face the merge issue when you deploy.
Example: I disabled the debug on the LHS and deployed. 10secs later, i look at the RHS and see the debug is enabled but there are no messages coming in! I decide to change something innocuous and I am faced with the merge toast.
Now play that out as server side state (instead of flow modification) and instead of displaying a toast about flows changed, the editor simply updates the state of the debug button on connected clients!
EDIT
For the record: This is a thought experiment - what I am suggesting may ultimately not be feasible
