I have a ValueTree that lives in my AudioProcessor class. It’s the brains of the entire plugin. My UI can set properties of this ValueTree, which in turn triggers a listener in my AudioProcessor class. The ValueTree is used to store purely abstract data, and the processBlock never tries to access it. Is this acceptable? I’m worried in particular about the listeners, although in practice everything works just fine. I just don’t want to paint myself into a corner so to speak.
I thought it about some more, and I realised my programming skills don’t yet permit me to laugh in the face of conventional wisdom. So I’m going to just restructure my code. 
I don’t see anything wrong with that, just be aware that the listener callbacks won’t happen on the audio thread (which is good!). It depends on what you are doing in those callbacks, make sure you stay thread-safe!
IIRC the callbacks will be called on whatever thread the original method was called that triggered them. EG if I call setProperty on thread A, the listener’s valueTreePropertyChanged will also be called on thread A.
I seem to change my mind every few weeks about whether the processor should actually do the work of responding to any state changes itself, or if something else should respond to them and simply inform the processor about the result.
Most recently I’ve been trying to keep to a strict MVC structure. The model/data of the plugin is certainly held by the processor so that’s the only thing it should do. The view is of course the LookAndFeel for the plugin, and the controller is the editor.
It’s not perfect since the processor not only holds the state of the plugin but is also responsible for the actual audio processing, but I usually just forward that to a dedicated object. And the view/controller line is a bit blurry since Components both handle the look of the plugin and how it behaves.
That’s a very long way of saying that although there’s probably nothing technically wrong with have the processor listen to state changes, I would personally prefer to have another object handle the plugin’s state and inform the processor of any changes it needs to be aware of. Especially in the case where the changes are only coming from the GUI side of the plugin - I try to make my audio processor completely unaware of whether or not it has an editor and so remove anyhing to do with GUI work from it and put such things in the editor.
Good point, your processor MUST be totally unaware of the editor, if the user closes the window the editor is destroyed.