The reason thin on thin is not generally recommended is that using thin provisioning on two separate layers increases the chance of out-of-space conditions for the virtual machines in this configuration. As ESX has evolved with new VAAI features, better reporting and more aligned communication with the array this recommendation has relaxed somewhat. With the coming advances in ESXi 5.0 and vCenter 5.0 certain array-aware features reduce this possibility for this event even further. That being said, with virtual machines that absolutely cannot have any risk of running out of space, we highly recommend zeroedthick (for better reliability) or even eagerzeroedthick (for absolutely reliability) in those cases. There is a slight performance overhead between thin and thick VMDKs but with the advent of block zero and hardware-assisted locking (ATS) that difference has become almost negligble (assuming you are running ESX 4.1+ and Enginuity 5875). When it comes down to it, it depends on how risk-averse your organization is. If thin on thin is desired, alerts on the vCenter level AND the array level (SMC alerts for instance) need to be created to prevent problems. With proper care and planning these risks can be greatly diminished.  This document will be updated with new information around GA time of vSphere 5.0.  Thanks  Cody
On page 26 of the EMC document "Implementing Symmetrix Virtual Provisioning with VMware vSphere" it indicates that for thinly provisioned symmetrix disks, the option to "allocate and commit space on demand (thin provisioning" should not be used.  Since storage admins here can't control what happens to LUNs after they are provisioned, we would like to know WHY this is not recommended and what the impact could be.  If anyone has insight as to why having the VMware hypervisor manage thin provisioning in addition to the the V-max - please share!
ESX New Virtual Disks on V-Max "What is wrong with using Thin on Thin"