1. Instead of running 10 services on one physical machine the way we used to, you run one service per VM (one web server, one middleware server, one database server, etc) - you add the overhead of multiple operating system runtimes, but thanks to awesome hypervisor optimizations identical memory pages are merged, so you don't use any more RAM
2. If one server gets over-subscribed, you just live migrate a running service to a less loaded server. No more building the infrastructure on another server, and doing a dump/restore process, updating DNS, etc
3. If servers are under-subscribed, you can consolidate services on a smaller number of servers and spin down the under-utilized ones - saving power.
4. High availability - have services monitored, so that if they host they're on goes down they're immediately brought up on another host - you can even have redundant copies of the VM running all the time so that you don't have any downtime if a host goes down
As to your question about whether it makes sense to size applications to servers... servers these days are way more that your typical application needs. It would be wasteful to use a 16 core, 500GB RAM server for a web server. Virtualization gives you a way to run this hardware at capacity. I suppose you could run multiple services on one OS, either in the same OS or in containers (as another commenter suggested). That's certainly a valid approach, especially for scale-out applications which you find in global web app vendors like Google or Facebook. Virtualization allows you to get all of the benefits of mutualization, with the ability to run multiple host OSes, provide granular access to people using the infrastructure, and providing a high level of security against jailbreaking applications.