Alrighty a guess and some homework for you is all I can offer on this today:

So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node.  (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing.  In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop.  So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.

So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map).  The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.  

So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances.  If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.

On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.