But I read that making heavy use of this type of over-commitment of memory (virtual memory allotment vs. working set size) is the rule in cloud architectures.

I think that there is a clear distinction between overcommitted allocation and overcommitted memory use.

Whilst I agree that it is quite normal for the total, of the memory allocations of all the VMs running on an individual cloud server, to exceed the physical memory of that server; that does not mean that the physical server is overcommitted. Ie. It's fine for server with 4GB to run 4 VMs allocated 2GB each, so long as the sum of the actual usages doesn't exceed 4GB. That would only happen if two or more of those actually used their full allocations.

But, AFAIK, that can't happen! At least not on any of the more modern hypervisors.

Because any hypervisor worthy of its name will detect the attempt to overcommit the physical memory and move one or more of the VMs to a different server. (And equally, detect a machine with under utilised physical memory, despite being overcommitted VM allocation-wise, and attempt to ship in another VM or two to utilise it.)

It's also possible to allocate a VM with more cores than the physical server possesses -- both Oracle VirtualBox and MS Virtual Server will allow me to specify that a VM is allocated 32 cores and run it on my 4 core commodity box; and I'm pretty sure (but don't actually know), that VMWare, Parallels and the other "big guys" in the field can do the same -- but it doesn't mean that those VMs actually get the benefit of those overcommited cores.

(Indeed, the suffer from it because you have the guess OS carefully scheduling the VMs threads across the 32 cores, completely oblivious to the fact that the hypervisor is then mapping them back to the 4 actual cores. And whenever you have two schedulers try to manage the same resources; they fight with each other and that costs dear. Same problem with languages that use their own scheduler and green threads; the two fight and nobody wins. )