The problem is that the tests are flawed and the native speed being slower as virtual is a pretty big red herring for that. That's OK because benchmarking that tests what you are after is actually very difficult. Small assumptions can create big differences. If you can't guarantee that the data has actually been written to the disk then you're testing caching mechanisms, something you already point out in your article, but then you're no longer testing file system performance as the article claims it is benchmarking. The problem is that we don't even know which caching mechanisms (guest OS, hypervisor, hard disk driver) or that the conditions are always the same.

A typical thing that performance benchmarks do to negate guest OS caching is to process significantly more data as what the available RAM is set to. For example, if your guest OS RAM is set 512MB, process 10GB of random data. Of course then the question is how-to get random data as you don't want to end up testing the random generator ;) or your host OS caching.

Another way to make sure you test data committed to disk could be to include a "shutdown guest OS" part and measure total time until the guest has been fully shut down.

I know that at least VMware has the ability to turn off disk caching (in Fusion, select Settings, advanced "Hard Disk Buffering" <- disable). I am not aware of a similar feature in Virtual Box, it might exist though.

Even while you tested the same guest OS, we don't even know if the hard disk adapters where both using the same hard disk drivers. Performance differs between IDE/Sata/SCSI drivers. SCSI drivers have queue depths, IDE drivers have not.