I'd say my answers today are pretty similar to what they were in 2009 when this article was originally posted.

The main issue I see with consolidation of any type is that you have to know your business requirements, your performance requirements (minimum, average, and peak, particularly IOPS), what the current hardware can handle, and what the new setup will provide. Consolidating five systems that each use most of a 5 year old, 2 core, 2 hyperthread, 2Ghz CPU with 8GB of RAM and 6 15k 3.5" disks onto a new system with 8 modern 1.8 Ghz CPU's, 48GB of RAM and 6 10k 2.5" disks is just asking for IO performance issues (six 10k disks do NOT provide the performance of thirty 15k disks). If you replace the 10k 2.5" disks with SSD's, then unless you have a CPU edge case, you're likely to see better performance.

The number one planning problem I see is taking N systems with M disks, and consolidating them into N/30 systems with N/15 disks of similar performance; suddenly, you're lacking the IOPS to run most of the loads at once... for instance, at the end of the month/quarter/year.

If you need either very high minimum or very high maximum performance, then be wary of consolidation. If average performance is what's important, consider consolidation strongly; instance-based consolidation in particular saves on maintenance effort at the expense of everything going down at once for reboots.

Note that VMWare ESX(i), at least, has quite reasonable resource management - you can assign minimums and maximums, set the number of "shares" for CPU, memory, and disk IO priority, and dedicate resources (dedicating some RAM and a certain amount of CPU is a means I've seen used to tune minimum performance).