I prefer a bit of competition.
But rather than have multiple companies working on incompatible implementations of the virtual machine monitor component, it's better if possible for them to standardize on a single one. KVM is not a full virtualization solution, after all. Look at this patch: it may very well be all that is needed for VMWare Workstation to use KVM internally. That ought to demonstrate how these kernel modules are effectively interchangeable.
Virtualbox and VMWare will still act and feel the same when they use KVM internally, just like they do on Windows when they use Hyper-V internally, or macOS when they use the Hypervisor framework internally, or like Virtualbox-KVM already does, some networking omissions aside.
The benefits of sticking to KVM are clear. If anyone has a problem in production, fixing it benefits every KVM user. If anyone wants to migrate between virtualization solutions, it's much easier when you can use multiple of them at the same time, whereas today you can't boot any of upstream Virtualbox, VMware, or KVM virtual machines at the same time on Linux.
(edit: And the benefits of not using out-of-tree kernel modules is even clearer; out-of-tree modules taint your kernel, preventing you from reporting bugs upstream, often prevent you from being able to upgrade to the latest kernels, are a pain to deal with when using secure boot, etc.)
KVM and hardware virtualization solutions can be useful for more than just virtualization, too; unlike Vbox and VMware, KVM offers a general interface for using these processor features. For example, there are some cases where it might be useful for Wine.
So personally I think it's fine. KVM is just a foundational part of a virtualization solution, and there's plenty of competition in the overall space.