Yes, we use BMC Remedy Action Request (AR) Server. As with most of our applications, we have 3 Remedy environments: DEV, QA, and Production. Each environment consists of a pair of Remedy servers. The application server which is the "brains" running the Remedy application as well as the email daemon. The other server is the "mid tier" server which is just a fancy name for the web server which runs MS IIS and Remedy mid tier. All end users go through the Remedy mid tier server to submit their tickets and to check status of tickets. That is to say, all our end users are using the Remedy web interface. A few Remedy admins run the Remedy Admin client. The mid tier server talks to the application server, and the application server data is back ended by SQL 2000.
So in summary, we have 6 Remedy servers. All are VMs and we haven't had any issues running Remedy inside VMs (although I did test somewhat extensively at first because Remedy is Java driven and I was concerned about the context switching). About 2,500 end users hit our Remedy servers.
Going from memory, each Remedy server has about 1GB of RAM allocated to it (if even that, I can check tomorrow if you want to verify). Each Remedy server is single vCPU running on HP DL585G1 AMD Opteron dual core hosts. But since each VM only has 1 vCPU, dual core or vSMP has no bearing on current performance which has been absolutely fine.
If it would help you at all, I can get you some historical screen prints of our Remedy server performance to show you the CPU/memory/disk trending.
One thing I really like about running Remedy on VMware is come patch time, I can throw the Remedy servers into snapshot mode. Remedy patches can be hairy and a snapshot is my ace in hole for recovery.
There's nothing simple about a Remedy installation. Make sure you get good install documentation. It's not so much the installation, but the massive configuration afterwards (which thankfully I have no reponsibilities for). Also note that each time you patch Remedy, it's basically run like a re-install so the install documentation is very handy at the time to. A Remedy install is anything but clicking next and accepting all defaults.
I do understand your Engineer's concern and he should be complimented on his due dilligence. Perhaps in a massive environment with tens of thousands of Remedy users, running Virtual might be a concern, but not at our user count of 2,500. As I said before, context switching was a concern of mine but it's been running just groovy. The improvements that came with VI3 helped in the kernel mode call area but I will say that we ran the same Remedy environments on ESX 2.x before we upgraded to VI3 and things were still fine then.
Let me know how I can be of more help in this.
VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
Sbeaver, that's always my intent...the more virtual the better, but the powers that be don't always agree 
