Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.
I think jBridge might actually collect the result of the subprocess in the next DSP tick. This means that the thread can go on to compute "C" because it can take the result of "B" from the previous DSP tick. Now you indeed have things run in parallel. However, this adds additional latency of 1 audio block. If you have several of such sandboxed plugins in a row, this can easily add up.
This is technique is sometimes called the "pipelining" (see "2.3" in https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11...). Note that you don't need sandboxing for this. You can just as well dispatch items to a thread pool, so everything stays within the same process.
So I think the speed up you observe with jBridge has nothing to do with sandboxing per-se, but is just a side effect of its implementation. I can't prove this because I can't look at the source code, but for me this is the most likely explanation.
Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no CPU usage change), but I can't test with VSTs right now (none installed). Maybe VST hosting has that problem, but processing of audio summing, Live's own devices and M4L doesn't have any major problem with multi-core.
Sidechain is not mere grouping/routing like the chain PaulDavis described with ASCII art (different from Sends too), with sidechain the plugin needs the audio from the other track for actual DSP processing, that's why sidechained tracks become a single thread "dependant" signal flow.
That page also mentions Live can use one thread per Chain if needed (for non Live-users, Chains are internal routings inside one single track), so it clearly states Live can use more than one core for one single Track.
Also, plugins like u-HE's use multicore just fine for a single instance, if you disable their own multicore handling (which conflicts with Live's multicore handling).
For Live's own devices, I'm pretty sure multicore works just fine, just tested again with Groups and Sends.
Don't know what problem you have, but it is not simply Live's multicore handling, it is some specific scenario you hit upon.
