Be forewarned Micheal, that article (and most MS Service Broker performance articles) are focused on how to increase performance of Service Broker by reducing the overhead and impact of Service Broker itself. As such the kind of tasks that are being serviced by the Activation Procedures are extremely low latency tasks, so that they can focus on the load from SB.

What they do not usually look at very much (and what I feel your principal performance concern is going to be), is what the performance impact/overhead of concurrency and locking stalls in the service tasks themselves is going to be. That is never easy to assess, and I do not know any hard and fast rules other than "always test".

A theoretical upper limit is easy to set: it's the number of CPU threads plus the number of disk spindles that will be used by your service tasks. In theory, you can never have more tasks physically "in service"(*) than that anyway. Anymore than that and the excess would have to be physically "in queue" for resources, instead of in your Service Broker's queue.

The real question then becomes, between One(1) and that number, when does the CPU task switching overhead and/or the effect of disk-head slewing from random access, and/or the hidden subtle logical effects of locking on the tasks, outweigh the benefits of maximizing the physical resource utilizations?

And there's no generally solvable formula for that. (well there is for the CPU part, but not the other two).

(*-- "in service" and "in queue" are the the Performance & CP technical terms for using a physical resource and waiting to use a physical resource, respectively)