According to the official documentation for VirtualBox v6.0:

Oracle VM VirtualBox can be used on a Windows host where Hyper-V is running. This is an experimental feature. No configuration is required. Oracle VM VirtualBox detects Hyper-V automatically and uses Hyper-V as the virtualization engine for the host system.

Well, that did not prove to be true in my case. Hence the experimental clause, I guess. A little googling revealed that, indeed, it did work for a while, then a new Windows 10 release broke it again:

The Hyper-V API became a viable reality with 1803, practically with 1809. And it went fine with 1903. And it broke with 1909. Please use your favorite search engine for “Immature API”… (source)

Even if it did work, however, you’d run into some (possibly) severe performance degradation. Quoting from the same official documentation page:

When using this feature, some host systems might experience significant Oracle VM VirtualBox performance degradation.

If you don’t need to run WSL2 and your VMs simultaneously, one workaround is to disable WSL2 in the Windows Features. There, you have to disable Hyper-V, Virtual Machine Platform, and Windows Subsystem for Windows. Yes, I had to explicitly disable all three of them. When you eventually reactivate them, WSL2 will start working again, configurations included.

Another option is to fallback to WSL1. That will work. Unlike WSL2, WSL1 does not run in a VM. Also, converting back and forth between WSL1 and WLS2 is dead simple. I did not go this route because, well, I like the performance that comes with WSL2. I also plan to use VirtualBox only rarely, when I need to test new versions of our desktop application’s installation procedure.

This is all not ideal, of course. The situation is evolving. This ticket on the WSL documentation repository is probably the place to watch for updates.

Hopefully, soon, once the currently “immature API” stabilizes, I will be able to come back to this article, edit it, and note that now everything works as expected.