Something I encounter frequently in the field is the use of Resource Pools as nothing more than organizational containers. This is not a good idea as this can have many implications on your VM utilization and performance. As a best practice, you should use the folders feature in the "VMs and Templates" inventory view for organizing your VMs into logical groups. Administrators typically do this because they default to the "Hosts and Clusters" inventory view.
Frank Dennemen, among others, has a really good explanation on the impact of using Resource Pools as organizational containers. Frank goes on to explain that simultaneous vMotions are restricted under certain Resource Pool configurations, which is also documented in KB 1026102 but I noted that the KB is related to vSphere 4.x only.
Indeed, testing this out in a vSphere 4 lab I find that if I have a VM migrating from one server to another AND changing Resource Pools in the same cluster my vMotion migrations are serial (note one active and the other waiting).
However, if I perform another vMotion without changing Resource Pools, they are allowed to progress simultaneously.
So, does this limitation still apply with vSphere 5? It would appear not, but I haven't found any official statement to that effect. I did conduct an experiment with vSphere 5 in the lab and found that I was able to vMotion two VMs simultaneously under the conditions stated in the links above.
I created a three node cluster and three Resource Pools. I then placed one VM each in two of the resource pools and on two of the ESXi hosts.
From there, I kicked off a vMotion of both VMs, selecting the third host AND designating the third Resource Pool as the target. As you can see, the vMotion requests are both actively running and they eventually completed.
Other iterations mixing moves between two different Resource Pools as well as to a host external to the cluster all allowed simultaneous vMotions.
I still do not recommend using Resource Pools as folders in vSphere 5. But at least you can now employ Resource Pools without concern over this particular limitation.
If you do use Resource Pools, you should leave unreserved CPU for overhead (10% for clusters and 30% for hosts). See the vSphere 5 vMotion Performance Best Practices Guide for more info.