The relatively short beta program doesn't install too much confidence in VirtualBox's stability.
Plus, given the relative advantage qemu/KVM has performance wise [1], VB is looking far less attractive than it used to be.

I am sceptical about most virtualization benchmarks because of the number of unknown factors involved. One they mentioned--by default, virtualbox caches writes that should sync to disk, inflating the results unsafely. QEMU/KVM can be configured to do this too. Another is that you can't be sure inside a VM that a measured second is really a wall clock second, since the clock ticks can get optimised out (this is why the clock slips in vmware when you don't have tools installed). If you can't reliably measure time, you can't do any xyz/second benchmarks reliably.

Anecdotally, I find QEMU/KVM to be absurdly slow on IO when using qcow2 and when the disk image is mostly unallocated. Once it gets allocated (grows), it's not as bad. An example would be compiling a kernel on a brand new guest. The first compile allocates a lot of real disk space in the qcow2, pegging the real hdd with metadata updates, etc. The next compile (after rebooting, so it's not caching) doesn't because the qcow2 doesn't really have to grow for it.

I have read that how bad this is might depend on the host FS (I use ext4), but I haven't tested this.

I am sceptical about most virtualization benchmarks because of the number of unknown factors involved. One they mentioned--by default, virtualbox caches writes that should sync to disk, inflating the results unsafely. QEMU/KVM can be configured to do this too. Another is that you can't be sure inside a VM that a measured second is really a wall clock second, since the clock ticks can get optimised out (this is why the clock slips in vmware when you don't have tools installed). If you can't reliably measure time, you can't do any xyz/second benchmarks reliably.

I tend to be skeptical about benchmarks just as you.
However, according to my own private experience, qemu/KVM runs circles around VB once you start adding cores, memory and network devices, and this without using virt-io devices. (I require "real" e1000 devices on my VM's).
As for wall clock vs. real clock, well, with NTP enabled, I never experienced any massive clock drift on x86_64 guests, and I relay on having synced host / guest clock for my software.

Anecdotally, I find QEMU/KVM to be absurdly slow on IO when using qcow2 and when the disk image is mostly unallocated. Once it gets allocated (grows), it's not as bad. An example would be compiling a kernel on a brand new guest. The first compile allocates a lot of real disk space in the qcow2, pegging the real hdd with metadata updates, etc. The next compile (after rebooting, so it's not caching) doesn't because the qcow2 doesn't really have to grow for it.

I have read that how bad this is might depend on the host FS (I use ext4), but I haven't tested this.

I only use raw images so I can't really confirm or contradict your observation.