Using Azure SB will break the technology golden rule by increasing number of technologies the project depends upon :)
While by using spirits I can actually reduce the number of tech (replacing already used in-memory and file-based queues with sockets) at the same time with improving throughput. Besides this will bring closer the experience of Rackspace and Azure deployments (allowing to have same maintenance tools).
Azure Service Bus sounds like a natural fit here when hosted on Azure. Some people are publishing an absolutely massive amount of messages through it so scaling of messages shouldn't be a problem there. Much better in throughput and scale than Azure Queues from my understanding.
For my Continuous Client demo I wired up Azure SB manually in 2 hours. Using the SDK likely even faster :)
We're doing slightly simpler approach, the brute force way. In short - if system is under load (queues get packed), we just provision more workers (virtual machines) to help deal with the work. Properly designed systems can handle 250x increase easily. Less thorough systems do only 15x increase (or much less).
Once the work has been dealt with - de-provision the excessive workers (and pay only for the hours that have been used - that's the beauty of the cloud computing :)
However, one of the primary bottlenecks of this approach is that when you ask for more workforce, it also increases the overall amount of messages that fly through the system (starting to kill primary queues, brokers, IO etc).
The idea with these small socket-driven spirits is to have everything constructed in a way, that when new workforce comes in, it also brings in more infrastructure capacities with itself, increasing in total throughput, redundancy and reliability. Somewhat similar to p2p networks (but dead-simple in topology). Sounds crazy, I know :)