I understand how splitting components across domains can maximize parallel downloads, and enable you to have cookie-free static content domains, but since there's a time cost for each domain lookup what is the optimum number of domains to use?
My recommendation is that for relatively simple sites, one "static content" domain should be sufficient. DNS lookups should be cached, so only affect the first contact with that server, but it should still be kept to a minimum.
Of course, there may be situations where more domains are appropriate (e.g. a photo hosting site may offload the photo serving to another separate domain).
I can think of one edge case where the benefits of multi-host requests outweighs the DNS setup costs.
When serving map tiles from a Google Maps-style slippy map, you can see benefits from distributing your tile locations virtually across a much larger number of hosts, even if they are all pointing at the same underlying resources (images). In these cases, you'll want to ensure that the resources have an "affinity" set to one host based on their properties (such as some combination of the MOD of row and column numbers) so that browser caching works optimally and requests are balanced across all hosts for any given view extent.
This situation is very specialized, but it basically just emphasizes that if you have a non-standard use case make sure that you test everything, and don't forget to include both raw numbers and UX / perceived performance of all of the scenarios.