There is no general rule to use or not use multi-threading. But the basic problem might just come down to how realtime everything really needs to be. If everything really needs to be as realtime as possible, you’re a bit screwed, because at some point you will need to put all the processing together to give it to the audio driver, and on non-RT OSes you have no guarantees as to when a chunk of work is finished.
The more you can relax the “realtimeness”, the more you can add some latency, and the more latency you can afford, the less it’s about how long some work takes in the worst case, but rather than how long it takes on average.
DAWs will go out of their way and try to relax realtime requirements, so they will e.g. run only the currently selected or “listening” track with low latency and do some sophisticated graph scheduling to pre-roll as much as possible. To do that, you need knowledge of the “future”, which the DAW has.
Most DAWs will also try to schedule all the plugins and stuff in a way so that they can somehow balance the load on each core reasonably, obviously to get most out of the available processing power versus time constraints. The more they know and are able to predict how much time a plugin needs to process a frame, the better this works. And of course, to do that, the DAW needs to be in charge of things.
When you do multithreading in the plugin as well, it becomes much harder for the DAW to measure and predict what you’re doing, because it doesn’t “see” the additional threads you spawn, and it doesn’t understand that you sometimes have to wait for some synchronization. Also, your plugin’s extra threads now compete with those that the DAW is trying to manage, making it much harder for anyone involved to manage what’s going on.