I understand where you're getting at, but I'm not convinced that's the issue here (BTW, KB1017253 has the directions to change those values). In 2.0, I never had to change any of the soap timeout values in vCenter/ESXi, and the OVF export task took 30 minutes for a 16GB thin-allocated template - lasting well beyond the 15 minute default it supposedly has according to the KB. It never gave me any problems, even if it took a long time to transfer.
I've been monitoring the staging area size in vCC nodes and the vCloud director server's transfer directory size during the transfer, and it looks like the transfer is indeed happening during the OVF export - just that vCenter decides to fail the OVF task before any tasks initiated by vCC can complete. If the vCC task is now at the mercy of those timeout values, then it's still impractical to use vCC for cloud transfer save for very small VMs. I am aware of the new so-called path-optimized transfer method that 2.5 has implemented, but if that means modifying the timeout values on vCenter/ESXi for large VM transfers, then it's still impractical to use vCC to move multi-gigabyte VMs (which would be the norm) across clouds.
Regardless, I tried with the timeout value of 3 hours (10800 seconds) on both vCenter/ESXi/vCloud, and it still failed with the same problem. Unfortunately, I don't have direct access to VMware support for this.
Enabling UDT on the nodes doesn't help at all - it just allows more data to be transferred before it fails. Given how it acts, I'm not sure how people are supposed to move their VMs to vCHS with vCC.