No worries, happy to try and help where possible.

1. The process I've followed in the past with sizing VM's appropriately is in the case of physical-to-virtual migration, run some software such as platespin recon which will monitor resource usage patterns over time (4 weeks or so).  This will give a recommendation on how many CPU's, how much mem etc, to allocate to the VM.  If I've been asked to spin up a new VM with more than 2 vCPU's I'll normally ask why the extra compute is needed as in most cases people immediately think "the more the better" which can cause unnecessary contention on the hypervisor when all those vCPU's aren't even needed.  If you think you have a server that will be demanding on the cpu, then give it 2 and see how it goes over time.  Monitor resource usage from both within the guest and at the esxi level.  If you find you get insufficient performance run perfmon and see what the guest is doing.  High cpu usage for one vm will suggest a bottleneck and an instance where increasing the vcpu count might improve performance.

2. When you configure a VM with an RDM, you can select either direct access to the lun or virtual access which is where a file (a link to the physical lun) will be stored in with your VM on the datastore.  If you snapshot the virtual machine when it has physical access to the rdm, it will only be able to snapshot any virtual disks (vmdk's) and thus any changes on the rdm will not be able to be rolled back.  When it's a virtual rdm and you take a vm snapshot, it will write changes to the vmdk on the datastore instead of on the rdm so you will still be able to roll back.

3. I just meant a Thin Provisioned virtual disk.  If you pre-allocate a 2TB vmdk to a vm and it isn't full, then you want to back that vmdk up at the esxi level, thats a big file to store.  A Thin provisioned disk is only as big as the utilization of said disk, could mean a smaller file to backup unless you're using the entire 2TB's.

4. A couple of options:  Have the OS drives of all VM's in vmdk's on an "OS" datastore (my guess is you're already planning/doing this).  Have a seperate Datastore for app disks that perhaps have data that may not be suitable for vmdk backups, put your 2TB vmdk in this datastore.  Configure ESXi level backups to only occur on the OS datastore, leave the in guest file backup in place for the 2TB drive only.  Alternatively just make a 2TB lun for the mail server and again do an os-level backup of that drive?  Sorry I'm not very experienced on the backup side of things so these suggestions may not be the best solution...