Over on the Fediverse I said something I want to elaborate on:

One of the reasons I still prefer BIOS MBR booting over UEFI is that UEFI firmware is almost always clever and the failure mode of clever is 💥. I dislike surprises and explosions in my boot process.

Old fashioned BIOS MBR booting is very simplistic but it's also very predictable; pretty much the only variable in the process is which disk the BIOS will pick as your boot drive. Once that drive is chosen, you'll know exactly what will get booted and how. The MBR boot block will load the rest of your bootloader (possibly in a multi-step process) and then your bootloader will load and boot your Unix. If you have your bootloader completely installed and configured, this process is extremely reliable.

(Loading and booting your Unix is possibly less so, but that's more amenable to tweaking and also understandable in its own way.)

In theory UEFI firmware is supposed to be predictable too. But even in theory it has more moving parts, with various firmware variables that control and thus change the process (see efibootmgr and UEFI boot entries). If something changes these variables in a way you don't expect, you're getting a surprise, and as a corollary you need to inspect the state of these variables (and find what they refer to) in order to understand what your system will do. In practice, UEFI firmware in the field at least used to do weird and unpredictable things, such as search around on plausible EFI System Partitions, find anything that looked bootable, 'helpfully' set up UEFI boot entries for them, and then boot one of them. This is quite creative and also quite unpredictable. What will this sort of UEFI firmware do if part of the EFI System Partition gets corrupted? Your guess is as good as mine, and I don't like guessing about the boot process.

(There's a wide variety of corruptions and surprises you can have with UEFI. For example, are you sure which disk your UEFI firmware is loading your bootloader from, if you have more than one?)

In theory UEFI could simplify your life by letting you directly boot Unix kernels. In practice you want a bootloader even on UEFI, or at least historically you did and I doubt that the core issues have changed recently since Windows also uses a bootloader (which means that there's no pressure on UEFI firmware vendors to make things like frequent updates to EFI variables work).

It's possible that UEFI firmware and the tools to interact with it will evolve to the point where it's solid, reliable, predictable, and easy to deal with. But I don't think we're there yet, not even on servers. And it's hard to see how UEFI can ever get as straightforward as BIOS MBR booting, because some of the complexity is baked into the design of UEFI (such as UEFI boot entries and using an EFI System Partition with a real filesystem that can get corrupted).