Apparently they are going for SBSA, which means it will have proper UEFI implementation, including possibly ACPI, so you will have normal UEFI experience.

At work we just got an aarch64 box from a vendor that has a very x86-like UEFI setup. Right down to the "BIOS" setup screens. It was very familiar seeming, but I'd rather have something like coreboot.

Coreboot only handles low-level initialization, it will still need a higher level payload unless you're going to hardcode your kernel to the board for every update.

Now, coreboot+tianocore uefi for somewhat open firmware...

This board appears to have some flash onboard, so it's at least better than booting from SD card.

The COM Express 7 module, has SPI-NOR for booting, a second SPI for UEFI secure variable storage, and eMMC for an embedded or recovery OS. Other than that you can boot your distro from eMMC, USB, Sata, or NVME.

The Minoca guys wrote a UEFI loader for RPi FWIW.

Could you please elaborate on how Raspberry Pi's approach is an issue?

Between the official boot firmware not being UEFI compatible and not being onboard it means you have to create a custom installation image and apply it to the disk rather than grabbing a generic installer and going. Also you need to do this for each bootable media you wish to create rather than once (and update each).

Philosophically, I actually like the RPi approach (ie. a simple image with device tree) a lot more than ACPI/UEFI. ACPI involves a whole super privileged virtual machine with byte code from god knows where, whereas device tree gives more or less complete control over to the kernel image (sure PSCI is a thing, but that's a lot more defined WRT boundaries to me than ACPI).

Basically an ACPI system is a lot easier to bootstrap because you don't need to support all of the little subcomponents of the board explicitly, but once you supprt devoce tree, you support the board in a much more complete and meaningful way, and it's truly your kernel running the show.