I think the only thing you can conclude from what you see is that there are differences in what you should expect from the yield() call across operating systems and that you should not rely on it for any sort of reliable benchmarking. You're getting into the area of reverse-engineering both Lightroom's threading model on each platform and the operating systems' own scheduling algorithms.
For example, there was another thread on this in this forum a while ago and someone noticed that Yield on Windows didn't return for 10ms (or was it 15?). If you look into available documentation on Windows' scheduler, the size of a quantum is either 10 or 15ms depending on the CPU configuration. Seems correlated, no? Maybe Lr's implementation on Mac isn't as tightly bound to low-level OS scheduling or maybe it is but Mac's scheduler just works differently. It will be complex to derive reliable info here: I see that my running instance of Lr on 64-bit Win7 has 33 threads just while sitting idle. What are they doing? Which are used for exports and plugins or does Lr start new ones for those? I wish you luck but I don't have high hopes for reaching a conclusion. And if you do, it could all be changed in Lr 4.
I've now disabled all other plugins, now I'm seeing steady 64 yield rate. I wonder why it was larger before, perhaps some of the internal plugins? I'm also getting single 1000 times per second yield peak when I close my plugin's dialog.
The point isnt really how slow or fast yield is, but if the plugin is getting any runtime at all. Ideally, I'd like to cancel the rendering when user changes slider value.
I doubt I'll be able to help much. but here are some things I've noticed:
Lightroom will not yield much CPU to plugins if its busy with something like rendering.
But also, plugins will not yield much to Lightroom if they are busy doing something, and not yielding.
Put another way, plugin will be CPU starved whenever Lightroom is busy, and
Lightroom will hang if a plugin is in an infinite loop without yielding (or sleeping...).
Put another-nother way, relationship between plugin and Lightroom is non-pre-emptive (in both directions), and plugin does not have higher priority than any of Lightroom's activities, not sure if it actually is last on the list or what...
I'm not sure how Adobe has handled making the develop module sliders so fluid despite constant need to restart the rendering - not a clue...
(I assume you've already noted the yield performance difference between Windows & Mac)
I don't know how apps like LrPad (remote develop module extension for iPad) have handled this, which has sliders that are supposedly changing dev settings in real time remotely, except that the sliders are in the iPad, not a plugin.
If I were doing this, I would *not* use a plugin for the UI, but an app that can take a slice of the CPU from Lightroom regardless of whether Lightroom is giving it (i.e. CPU scheduled pre-emptively by OS). Then, use a plugin just for the dev-setting.
PS - I have used http for app <--> plugin communication, as well as file-system.