(I will preface this explanation of the dispute at hand by noting that I am not an expert in these matters, and may get some things incorrect, etc.)
CPU architectures generally do not start in a mode where they are running standard instructions that they are documented with; instead, they usually start in some kind of “firmware” mode or something vaguely equivalent to it, and there is some program, embedded in the CPU or otherwise, that usually gets it out of this mode and into a more standard one, before invoking whatever the next boot step is.
On x86, this process is basically totally transparent to any OSes or even bootloaders; by the time any code an OS or bootloader developer has written is being run, the CPU is running in a regular and standard mode (when using MBR/BIOS booting on x86, this is usually … 16-bit real mode, emulating a good old 8088 or something close to it; it is the bootloader’s job to switch to 32-bit or 64-bit mode from there), and usually with some BIOS or other facility available to interact with hardware in a generic manner before you set up device drivers (e.g. IBM PC BIOS, EFI, U-Boot, etc.)
Generally, the layer that performs the truly early initialization and then provides the BIOS is CPU-specific, board-specific, and almost universally proprietary. Maybe it is technically reverse-engineer-able, or even documented, but modifying it is not trivial, and often not supported (“void your warranty”) and definitely not something OSes are ever in the business of doing. Such platforms are almost universally very machine-specific; on embedded platforms like RISC-V or ARM, they will often embed hardware addresses directly into the compiled loader, as there is no way of probing anything during this very early stage of booting.
On RISC-V, which is a truly open CPU platform, this lowest layer is actually officially documented (however, there are some major caveats even to this, it appears the specifications are deliberately looser about it, so this may not be such a strong guarantee), and so it is possible to write truly low-level boot platforms that do not rely on reverse engineering, at least in the abstract, instead of depending on a boot platform. X512 has written one of these, though it is limited to use in virtual machines (maybe just one virtual machine), and probably always will be; for any kind of real use on any bare metal device, either SBI, EFI, or some other like platform will have to be used as the bare metal device provides it.
So the question ultimately is, do we have a reason (if we are going to have to use SBI/EFI/etc. on bare metal, i.e. what Haiku is really geared at running on) to write, merge, and maintain a separate boot platform just for use in (maybe only one) virtual machine? That carries with it a lot of unknowns (for instance: developers that test on VMs may inadvertently break bare metal if they are using a totally different bootloader with different semantics) besides the added maintenance burden for unclear benefit. Hence why my own opinions, so far, side against this idea.
This is just a summary, I probably missed some things. But hopefully this makes the dispute more intelligible.