I'm thinking your issue might be more related to UEFI vs BIOS firmware and not encryption or TPM. If you're finding that UEFI is in use and disabling Secure Boot doesn't cause the problem to occur, then the use of encryption shouldn't matter either.

If Workstation detects that Hyper-V (or anything that depends on Hyper-V such as memory integrity or virtualization based security), then Hyper-V will be used as the hypervisor (search the vmware.log file of the VM and look for Monitor type: ULM). It's conceivable that the interaction between VMware and Hyper-V is what's causing this to happen. There was another issue with multiple CPU support and use of Hyper-V instead of the VMware hypervisor that reared its ugly head when VMs were updated to later Windows builds - that issue was fixed in 16.2.5 and 17.0. It sounds eerily similar.

If it's the same type of issue, then it is conceivable that VMware did not fix the issue for all possible cases - including if BIOS firmware is in use instead of UEFI.

If you can, I would file a service request with VMware so they get a chance to look at it officially.

It would be interesting as an experiment to disable Hyper-V entirely and force Workstation to use the legacy hypervisor.

Personally for any new virtual machines, I'd never use BIOS unless I absolutely had to. I know that this would create a problem for existing VMs using BIOS of course.