As you are probably aware already, to be precise you have only 16 with 32 threads, so you vendor still has room for complaints unless you buckle up for some 4-socket system.
Sounds like this is just another case of a vendor pulling out ridiculous hardware requirements from nowhere. Just because it contains the magic acronym "SQL" doesn't necessarily mean it will be a monstrous heavy-hitter per se. Not every database and application requires huge resources like this. Unless they can give you some solid numbers on how they arrived at this "best practice" and why it applies to your particular case, I would always doubt such requirements.
One of the beauties of virtualization is that you can have a good, unbiased look from the outside of how a system utilizes it's available resources. If it really needs more vCPUs or memory, you can easily add more (hot-add even).
The problem if you don't comply with their demand is that they might end up pointing fingers at this for every future issue with the application.
For the option of running this single VM with 32 vCPUs on a dedicated host, I doubt it will interfere with the "host operations" and overhead all that much unless the VM *really* consumes all the CPU cycles provided by those 32 vCPUs. Besides host processes, of which there aren't really any significant ones (except for software iSCSI and occasional vMotions) take priority over VM processes.