They've 2 use cases, this test one, which has a rationale linked from 'workload' in article:
"Run end-to-end, the 7,000 trunk tests would take about half an hour to execute. We split these tests up into subsets, and distribute those onto the 10 machines in our Jenkins cluster, where all the subsets can run concurrently..."
...so clearly running these tests on a single devs machine would be a bottleneck. The other use case is the dev env: in a previous blog they described how they're using their own internal cloud to run the dev vm's faster on dedicated hardware (with easy, one click provisioning):
which makes sense. Why emulate prod running on dev's own boxes when you can pool the hardware and get better utilisation, & at the same time run them faster?
It is a good way to have faith in your ability to execute your stuff on new/unfamiliar/heterogenous environments, which can be valuable. People may be geographically distributed. People may wish to work offline. People may want a degree of control not available or even feasible on shared hardware resources.
The 'offline' one I agree with, but don't think that's precluded (they have the chef recipes, so why not); but it's an option not the common case. And the last one too - we've got a similar setup, and there are times when there were issues with our xen vms that we explored outside of the shared cluster. One more justification would be overflow - this has happened here, we don't have room for all the VMs on the cluster so some of us run them locally.
So yes, don't rule it out, but still seems to make economic sense to share hardware.
