Ran into this problem today with an old server with a pair of 2697v2 CPUs.
The connection is just a gigabit but it would only yield 11MB/s to 25MB/s of speed when exporting a machine while none of VMs were running.
It's a test environment and I got full admin access to it so first I run iperf3 and got a healthy 930-950mbit/s of bandwidth.
Directly copying a file using SCP would offer up to 45MB/s but very unstable sometimes plummeting below 10MB/s.
I did observations with esxtop and concluded that the most likely bottleneck is the compression that happens to the very larger VMNAME_FLAT.vmdk into VMNAME.vmdk while transferring and the util doing it is strictly single-threaded because all cores would sit at 0-0.2% while one would be completely pegged.
People saying it must be an intentional bottleneck got probably got the misconception from the fact that you can export many VMs at the same time and each would work at same speed before saturating the NIC but it's because each process would take one core and servers usually got lots.
So dear VMWare team, don't you think it's time to either spend some quality time with the Greek oracle ladies (the ones handling.. threads you know) or at least give us some kind of choice such as compression quality or client-side compression? One core of client CPUs can usually beat server CPUs by quite a bit and with very fast network it could speed the process by a lot.
