That’s not quite true. All the APIs suggest separating the editor/processor as much as possible. Some more than others.
For example, VST3 is explicitly designed not only to support this, but encourages it and explicitly discourages direct communication between the editor/processor.
From the VST3 documentation:
this separation [between controller/processor] enables the host to run each component in a different context [process]. It can even run them on different computers.
The two VST 3 components (processor and controller) need a way to communicate. It is the task of the host to handle this.
Please note that you CANNOT rely on the implementation detail that the connection is done directly between the processor component and the edit controller!
There is a translation nuance in there, I take it to mean you can’t assume that there isn’t anything in between the controller/processor or that they are in the same process.
There is more, from
SingleComponentEffect (component = class instance).
Default implementation for a non-distributable [single process] Plug-in that combines processor and edit controller in one component.
This can be used as base class for a VST 3 effect implementation in case that the standard way of defining two separate components would cause too many implementation difficulties
Use this class only after giving the standard way of defining two components serious considerations!
JUCE doesn’t encourage that kind of architecture however. IMO the onus is on plugin developers to stop assuming their plugins will run editor/processor in the same process so host developers can stop allowing it happen, and rely as much as possible on communicating through the host. Most of the time you don’t need to create a channel between the plugin/editor directly.