This will be used by bhyve to build a device tree.
From my reading of QEMU, it always creates an FDT, then optionally creates ACPI tables and exposes them to the guest via fwcfg. I also had a look at EDK2's ArmVirtPkg, which I presume is what we'd want to use as the platform firmware when booting from ACPI (I don't really understand how Ovmf and ArmVirt overlap). From what I can see, ArmVirtPkg assumes that a FDT is present: the first thing that the module entry point is save a pointer to the FDT to copy later. The FDT is exposed to the rest of the firmware using a UEFI protocol, and fwcfg nodes are used to decide whether to pass ACPI tables to the guest.
So, assuming that we want to target edk2 on arm64, I think we probably need to keep the FDT builder even if bhyve is configured to supply ACPI tables to the guest.