Hey, wait a moment: were are the other benchmarks? Simply but: I didn't run any other benchmark. Why? The point is that in all benchmarks we would see the same repeating pattern: write-through mode would be the slower, with nocache and writeback ones way faster.
To tell the truth, I expect some variations in the nocache vs writeback cache mode because the latter can use the host-side pagecache, effectively accessing more memory as disk cache. However, any difference here would be very specific to a number of factors, most notably: host memory size, guest memory size, application read/write patterns, number of virtual machines hosted, number of shared backend file (eg: to support multiple snapshots)... In short, way too much to give you significant and repeatable results that will apply on your cases. Moreover, in other cases the implicit direct access granted by the nocache mode can give you a slight performance boost.
My suggestion is to use the write-back or nocache policies each time you can enable write barriers on the guest side (ie: all Linux distributions released in the last years). If you have a mostly read-bound workload, go with a write-back policy (as it permit to use additional pagecache memory), while for mostly synchronized-write-bound guest (ie: a PostgreSQL machine), use the nocache mode. If you can't enable guest-side write barriers use the nocache option. In this last case, for maximum safety you can use the write-through mode but be aware of the massive performance loss and the potential impact that the added disk activity can have on other virtual machines as well.
It's a very pleasing thing that Qemu/KVM storage stack now supports write barrier-passing on both VirtIO and IDE devices. All in all, the KVM project is evolving very well and it has a great future. I hope you find this article interesting.
Have a nice day!