Anyone have insight on it ? What's the utility of being able to disable virtualization ?
Even in case of "corpo disallows it" (for whatever idiotic reason) it can be turned off one way or another in OS...
I consider the option to disable (or rather: enable this function manually if you need it) virtualization to be quite useful because if this feature is disabled, malicious software cannot install a virtualization rootkit, i.e. a rootkit that makes itself a hypervisor and moves the current OS instance into a virtual machine running under this hypervisor.
See for example https://en.wikipedia.org/wiki/Blue_Pill_(software)
As far as I know, it just enables a few new CPU instructions, but older software that didn't know about them wouldn't use them anyway?
So for 'broken' software (and there was a lot of it - even back in the day of the turbo button) it often can be better to just not allow the software to see/use all the hardware.
Example of the weird stuff you have to first know about, then detect and then mitigate, on a per-device basis: https://marc.info/?l=linux-iommu&m=139305749014927&w=2 and that's something that when you don't do it, the software doesn't deal with it very well. Since not all software can be influenced by its operator (be it lack of skill, resources or simply legally not allowed), it can be much easier to just have a switch in the firmware where you can hide it from the software.
Switching code paths based on MSR is something that is one of the safest (and broadest) things you can do early on when you start up, so in a way, such a switch is merely "supplying configuration" but in a pre-boot fashion.
As another datapoint, I have a machine with VT-x enabled and Windows 98 runs fine. It just doesn't know about the extra features the CPU has (like it also doesn't know about it having more than one core).
The best combination is either software that knows the issues for each implementation and can work with it, or software that doesn't use the features (either not using them natively or by making it unavailable to the software).
It's amazing how string-and-chewing-gum some hardware is with software working around so many issues to not crash. Sometimes there is good documentation, errata or usable flags (like MSR bits), sometimes it's just 'lower the pressure until it stops crashing' and you get a fat list of quirks.
Corpo can disallow that too via central policies
(Edit: of course, that wasn't the case when this particular article and BIOS was written.)