That must have been one horribly run virtual infrastructure. AES-NI and AVX2 are available within VMs, atleast when using VMware vSphere. VMs generally are more stable because there are no hardware driver issues within the virtualized OS since you are using the same drivers (from VMware) for every server and they are incredibly stable. Storage I/O is a function of your storage and transport, not virtualization. We run solid state storage arrays with sub 1ms latency continuously and easily handle over 1GB/s throughput.
There are very few applications that don't run better on a proper virtual infrastructure, but it does have to be engineered correctly, which it sounds like whatever you tried before, was not. This is the type of stuff I manage and build everyday, but maybe you have something unique that I haven't seen before.
Unfortunately, VMs are something you can use only if you don't need latest CPU technologies such as AES-NI, AVX2 etc which we heavily rely on. Also, to our experiences, VMs do not have such good uptime. There are many sporadic issues such as sudden reboots and upgrade maintenances, disks are terribly slow, private network outtages that also cause issues with storage I/O etc.
What happened should not have happened, but it did anyway. However, the chances of this happening are very very very slim, so we do not expect something like this to happen again.