Ok my perspective for general enterprise mixed workload.
16-20 core / 256-512gb ram (e5 v1/2)
28 core / 512gb ram (e5)
40 cores / 768g ram (scalable)
See a trend here, 16+ gb/core
Isn't this entirely dependant on workload though? Yes it's a starting point but I think it's a bad assumption to start with "system has X CPUs and therefore needs X*Y GB of RAM" - I've seen countless cases where people have taken this rule of thumb and applied it religiously even when the workload hasn't warranted it. I've seen this is the physical world as well, not just virtual.
"Oh, you need to go from 16GB of RAM to 32GB of RAM to fit the dataset in to memory? Well then you'll also need to upgrade from 4 to 8 CPUs"
Which brings me on to your second point...
Keep the virtual cores low for VM (match requirements) if you go high you have cpu ready wait issues, more low core count VM’s can schedule more efficient than small number of large ones. Especially in ESX (less bad in KVM it seems)
This is completely correct and it can't be repeated enough because so many people seemingly fail to understand it - assigning more vCPUs to a VM than it needs will frequently result in poorer performance. To execute, say, four cycles on a 4 vCPU VM simultaneously, the hypervisor scheduler needs to wait for four of the physical CPUs to have a free "slot" all at the same time. The more VMs you have and the more CPUs they all have, the busier the physical CPUs become and the more and more times the vCPUs will need to wait for a free slot across however many pCPUs need to be made available. The kicker is that even if your massively overpowered VM never needs more than 4 simultaneous threads, if you've given it 16 vCPUs it still needs 16 pCPU "slots" to be available every time any of them need to run. Hence it's possible to get into a situation where you've running on, say, 50 pCPUs, your maximum workload needs 40 pCPUs-worth of processing power, but because you've allocated 120 vCPUs you can only achieve 20 pCPUs-worth of power because your hypervisor isn't able to schedule effectively because the VMs are continually blocking each other.
This "wait" time is called "CPU ready" by VMware at least, there's another brief rundown here:
CPU Ready: The Silent Hypervisor Killer - Appuals.com
It's less of a threat to performance than it used to be, generally due to the huge increase in core density we've seen over the last 10-15 years, but still an important factor to consider when gauging CPU performance. "Right Sizing" as it's called as an important component in making VM consolidations as efficient as possible but then there are plenty of people that don't care about efficiency or the increased cost.
Don't get me started on the number of arguments I've had with people who assume More CPUs == More Performance (again, not just in the virtual world either) without actually doing any performance analysis.
"We need this application to be faster! Bump the server from 16 to 32 CPUs."
"...but if you look at these performance stats you'll see it never actually uses more than 2. It looks like this bit of the code doesn't scale across cores..."
"So, if we increase to 32 CPUs it'll use 4 instead of 2 and be twice as quick! Get to it young man!"
Incidentally, this is the reason why enabling SMT on your hypervisors almost always gives a fairly drastic amount of extra CPU power "for free", simply because it doubles the amount of queues available to the hypervisor and makes stalls waiting for available slots much less likely. It's also a big reason why a lof of people have been badly hit by Intel's performance bugs.
