One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.