The thing is that doing a separation for editors necessitates that you create a "client-server" protocol and things needs to flow through it, and that adds quite a bit of complexity over a "plain" editor.
And for authoring tools, especially in gamedev that can really blow up in complexity, because you often want to create custom editors (imagine things like enemy paths, layered enemy paths, skin customization options, and so on) and every customized one risks adding more complexity to the protocol (unless ridiculously overspecified from start).
This is why "dear ImGui" is so popular (look at the example screenshots for the library.. tons of editors), the magic is that you can tie rendering of the editor to the editables quite easily so there is very little overhead in makin an editor (a task that normally can gobble up inordinate amounts of time).
Yes, I guess a big part I skipped is that it may not be such a good fit for action games, where asset-dependent interactions, such as collisions, can affect the game model.
But games closer to the tabletop end of the spectrum (think strategy, puzzles, etc.) are basically apps: they're not doing much in the world itself, but rather rendering it based on the existing state and accepting user input to modify that state.