Leaving aside the issue of user-replacable signing keys if some kind of measured boot system is in use, and availability of documentation so you can replace the firmware if you want, which isn't really UEFI's fault, there's other issues with UEFI as well. Such as:

- Why does it take 8 minutes to boot a UEFI server vs. 17 seconds with NERF? Minnich's opinion is that it's the braindead way UEFI initializes stuff. E.g. if thingy A needs thingy B, it will initialize thingy B regardless of whether it has already been initialized, etc.. Leading to a combinatorial explosion. Whereas Linux builds a dependency tree and initializes each thing only once, in the correct order.

- UEFI option ROM's apparently mostly contain x86-64 code and not UEFI byte code. Some clever guys at SUSE had managed to work around that on aarch64 by using qemu to run the option ROM's, and since the x86-64 and aarch64 data structure layouts are more or less the same (endianness, alignment etc.) they could share the memory space. I mean, it's an awesomely clever hack, but do we really want a Frankenstein thing like this be the bright future we're striving for?

- UEFI is amazingly complicated. Say if you want to load the kernel over HTTPS, you need a TCP stack, HTTP, TLS etc. Sure, Linux is also complicated, but I'm sure Linux is 1000x more battle tested than the UEFI stack. And, if you're going to run Linux anyway, you're not increasing the attack surface by running Linux as your firmware & boot loader. And, if you're using booting Linux from the rom flash, you can use Linux native drivers to access the NIC, storage, USB, whatever and don't need the kind of hacks mentioned above on non-x86.

Sure, using Linux as firmware & boot loader might be politically untenable to some proprietary OS vendors. But so what? Let them solve their own problems!