No, and this is one of the main reasons a CPU scheduler is necessary. They have to be divvied out as timeslices. Assume in your example we're looking more closely at a 1 second sample with 10 VMs sharing a non-HT core, and as of the beginning of the sample period, every VM has enough work to keep the 1000 MHz core busy for 100 ms. In this case, every VM effectively requires 100 MHz, but you would still see CPU READY times.
Each world is only given a time quantum of 50 ms by default (see page 6 on the doc you linked). In our sample period, for the first 50 ms, the first world scheduled would not change its own state to WAIT because it has 100 ms worth of work. After 50 ms, the scheduler would be invoked, and that first world would begin accumulating READY time, until the scheduler circles back around to it. While this is happening, since the other 9 VMs in this example also had work to do, they would have also accumulated 50 ms of READY time each.
This isn't accounting for I/O contexts or interrupts either. This isn't a typical scenario, but more of an academic exercise to answer the question I think you're asking. :smileyhappy:
Hope that makes sense!
EDIT: The answer is spelled out a little more clearly on p11. They're speaking more to skew mitigation for SMP inside the guest here, but the "one at a time" statement is true regardless of whether or not they're sibling vCPUs. If multiple busy vCPUs are ever sharing a pCPU, at least one of them will accumulate READY time.
To ensure that sibling vCPUs of a multiprocessor virtual machine are co-scheduled as much as possible, the CPU
scheduler avoids placing multiple sibling vCPUs on the same pCPU. If there are two busy sibling vCPUs of a virtual
machine scheduled on the same pCPU, only one vCPU can run at a time which may lead to co-stop and cause
extra migration. Better co-scheduling is accomplished by making the goodness greater if the destination pCPU
does not already have a sibling vCPU placed.