A few suggestions...
/boot 250 is fine we did ~256 to match allocation boundary, but not really critical
swap should be twice COS memory, so unless you are pushing Console memory to maximum of 800mb, 1600 is overkill
/root this is not right, it / that should be sized to handle surprises, such as /opt for example, you can break out /opt, /usr, etc. but for us it was easier to just set / to 8GB from default of 5GB and call it done.
/home, 4GB, but is overkill for us
/tmp, 4GB but is really dependent on how you use /tmp
/vmimages is use dependent. We actually create a separate VMFS partition, say /vmisos, where we stage ISOs, we stage exported VMs or VCBMounter CLI on separate LUNs on shared storage for snap-shots, /backup for example. We don't use templates much, but if we did, we would setup a dedicated shared LUN for these as well.
vmkcore, set by VMware
We break out /var as 16GB for two reasons, 1) with 73GB drives for OS, we had the space, and 2) we tend to keep our logs for a long time, for we wanted to make sure /var/log has lots of room, it has proven to be a good decision when trying to figure out chronic issues.
As for ESX 3.0.x version 3.5, we have yet to see any reason to change any of the above given that ESX 3.5 is typical of ESX 3.0.x in this regard. We are testing 32GB solid state drives for ESX 3.5 OS footprint, so we are thinking of shrinking /tmp, /home, etc. to 2GB, and /var to 8GB, moving /vmisos to shared LUN common to all ESX hosts, etc. to get the OS foot print down to less than 32GB.
