My support case I had for this has concluded (Case 00911701). Veeam opened a case with VMware and a Veeam KB has been created as a result: http://www.veeam.com/kb2052
The KB explains why the SAN restores are so slow. Basically it's because Veeam must constantly check with the ESXi host before every block is written to work out which block to write to on the disk next. This causes the slow down. If the restored VM was THICK EAGER then this wouldn't be an issue. When you use Network Mode for a restore the ESXi host preforms the write to the Datastore and it already has knowledge for the layout of the VMDK so doesn't have to keep checking which block to use next.
For now the best solution is to make sure your datastores are OFFLINE on your backup proxy and are not mounted. This allows a SAN mode backup to work, but a restore will failover to Network Mode. You get a warning during a restore that SAN mode is unavailable, but it then fails over network and the speeds are good.
It would be good if the restore wizard prompted which restore mode to use, but for now this is the best we have. At least Veeam and VMware have confirmed the cause and haven't found something we're all doing wrong.