Ugh... was only a matter of time before I encountered an abrasive know-it-all on here... GOD I hate arguing, especially in forums... anyway, here we go!...
Check the brakes buddy, I DID consult Dell/Compellent. Who do you think I worked with over the course of 2 months to accomplish this? Copilot Support Case# 133535. Look it up. Call 'em. They've written KB articles that outline what I discovered. I'm sure they'd be happy to provide you with the documents.
From Edward Sandberg, one of THE TOP senior escalation engineers at Copilot Support:
"You are correct, the ESX box does not inform us that the data has been moved. It rewrites it to the destination volume and then deletes its pointers to the data on the source volume without actually zeroing the blocks.
You have series 40s so if you are using ESX5 you could update your controllers to 6.0.5 and the new VAAI support would free space up when you do vmotions, but you'd still have to reclaim that space using UNMAP commands.
Other wise the only way to get the space back is to delete the source volume you vmotioned the datastores from."
Edward Sandberg
Enterprise Engineer, Compellent Storage
Dell | Support Services – Copilot Support
They even thanked me for my discoveries. From Wade Stahlberg, in DEVELOPER support:
"Thanks so much for the info you sent in. I have been spreading the word with other Copilots. I don't have an ETA but we are planning changes in our documentation as well."
Wade Stahlberg | Copilot Solutions Engineer
Office 952.562.3021| wade.stahlberg@compellent.com
Copilot Support | 866 EZSTORE | support@compellent.com
NOT TO MENTION, the nifty little "tool" you're refering to is called the "Windows Server Agent" and GUESS WHAT?!?! It only runs on WINDOWS! VMware ESXi however, IS NOT Windows! 
If you've worked with VMware, you'd know this.
So you see, by throwing out unsolicited advice and opinions and NOT really knowing all the facts that surrounds a topic or issue, you're really doing more harm than good in these forums