The main advantage is you don’t need to doink around with bootloaders. Using UEFI and ACPI makes an ARM board behave just like an x86 desktop or server. You can just take an off the shelf RHEL, Debian, or Ubuntu installer and it’ll just work. UEFI also enables a single disk image to be bootable across many different systems, as long as the kernel has drivers for all those things (distro kernels usually have a tremendous number of modules enabled for this use-case). You don’t need a device tree for each board you want to boot on, ACPI takes care of that as there’s actually a spec and interface format that doesn’t change (unlike device tree).
I’d argue that for a typical embedded product development flow, UEFI and ACPI don’t bring anything to the table over u-boot and device tree. But for things which the customer will treat like a server or desktop, it’s by and far the right way to go, if for no other reason than that’s how everything else does it and people know how to use it.
Unfortunately, the way the Raspberry Pi 4 UEFI works, you have to still stick a bunch of files into the ESP (EFI System Partition) which allow the ROM to properly fetch and execute the UEFI. So the disk itself has to have support for the Raspberry Pi, which is not normal. On a typical UEFI system the ROM support and UEFI itself would live on a separate SPI flash so you can blow away your disk or boot with no disk and still have your UEFI. So the Raspberry Pi UEFI method still has some drawbacks as compared to a normal server or desktop.