The problem with all of the alternatives is that they aren't friendly for alternative OS. They mostly operate on a fork model, so upstreaming support for an OS doesn't mean everyone using that bootloader will support your OS. You either need to pretend to be Linux with a sort of boot shim, or build and flash a custom bootloader with support, which might be non trivial if you cannot get access to the forked bootloader's code.
UEFI is just a standard interface, not an implementation of a bootloader. This enables multiple UEFI compliant implementations as well as an easy way for OS to support all UEFI based bootloaders without needing to coordinate with the owner of the bootloader. While I'm sure most would agree the UEFI interface may not be ideal, it has a lot of industry momentum, and is therefore probably the best option to get behind. There are a lot of players in this space (mostly hardware vendors) and coordinating anything is very difficult and takes a very long time.
OpenFirmware is similar level of complexity as UEFI, to be quite honest, and lacks certain mechanisms that were designed into ACPI (and inherited by UEFI) precisely to support multiple different operating systems without requiring the OS to be have specialty drivers for every little bit.
Sure, in the happy path, you can depend on OpenFirmware giving you parameters like locations and addresses and "this device is compatible with X so you can use its driver", but it still requires that you have the specific driver the device is compatible with, and a new hardware release was often incompatible with older versions of OSes because, unlike ACPI, you can't encode information like "Hey, I'm compatible with interface X version Y" => "here's limited functionality because your driver is not updated for interface X version Y+1 but the computer will work".
Instead you had special "hardware support releases" to get the OS to boot at all.
CoreBoot and uboot by itself provide even less support. They might have open source, but they provide effectively closed platform to the end user. UEFI is in practice less restrictive because I only have to program to the interface, and in absence of gross bugs, I can expect things to work - whether it's a boot-time driver to support my super-duper-special storage add-in card, or a custom OS that I want to be available for normal people to try out by running on their random home PC. Hell, if Linux kernel people didn't tell they would no longer accept "platform definition" patches, you probably still wouldn't have FDT used on ARM with uboot.
Nothing is perfect, and you are probably right that any firmware for potentially SMP computers with multiple types of boot device is unavoidably complex.
However, ISTM that relying on a magic partition on a fixed disk is a poor design, and while other types of firmware are not radically simpler, there are or were alternatives, and some of them are noticeably more FOSS. UEFI is EFI for x86-64, broadly, and EFI was proprietary. That is not a good thing, in my book. Something more cross-platform and less vendor-dependent would have been preferable, even if of comparable complexity.
I had a long dissertation here destroyed by random F12 and backspace key that I can't deal with retyping again, but I fully disagree.
UEFI mandates certain, user and developer and admin UX nice, minimums regarding boot process. You can fully expand on supported filesystems, or even non-FS sources to boot from. Even from paper tape if you want to. You're not bound to magic partition on a fixed disk[1] anymore than you're with OpenFirmware (and decidedly less than IBM PC BIOS compatibles).
None of the comparable alternatives were really FLOSS (by the time OFW went open source, EFI was shipping on x86 and amd64[2]), coreboot/uboot/redboot/etc were too limited, by themselves being e-waste framework unless paired with upper layer to provide open platform for users and developers.
EFI was available, back in 1.1 timeline, as open source code for x86 and IA-64 (the IA-64 specific bits were called "SAL" IIRC), then some bright mind at Intel decided to close it down. Fortunately they open sourced it back as TianoCore and we now have FLOSS solution (it's as proprietary as OFW at this point in time, and it's more of an open platform than uboot/coreboot/etc).
The available "less proprietary" options all created closed platforms, where you need excessive porting to boot anything the vendor didn't ship for you. It's trivial to make firmware so flossy it will make RMS shed tears of nostalgia for KA-10, but it's not going to be useful for majority if they ever want to run something not provided by vendor. Minicomputer/workstation complex firmware monitors etc. happened because diagnostics were often needed, and some required at least some compatibility with third party hardware, but them - including origins of OpenFirmware - implicitly accepted a closed platform where vendor would need to ship a special "hardware enabling" OS update or ship entire OS version to match new platform.
UEFI might have proprietary roots, but it (and ACPI) is designed specifically to provide for the case of freedom of end owner to run whatever crap they want, including older version of OS they already got used to.
[1] Unless the hardware is too cheap, like Qualcomm ARM systems with UEFI where various critical services are patched in windows drivers to be handled through magic files on ESP, or in permissible CHRP OpenFirmware variants where magic partition on fixed disk is explicitly mentioned as an option.
[2] EFI based firmwares started shipping by 2005~2008 timeframe on x86 and amd64, mainly due to DXE providing way easier method to integrate 3rd party code. It was also from start designed to handle multiple platforms, partially thanks to having IA-32 and IA-64 code simultaneously as early as EFI 1.0, which made it easier option to handle future 64bit platforms.
I've been in that situation. There used to be a very handy Firefox addon called "Lazarus" that helped. Quantum killed it. This may help - not tried it yet:
Unfortunately not. Proper writeup would require sitting down for some software (and hardware) archeology to dig out stuff that in some cases seems to have been pulled off the internet on purpose (original open source EFI 1.10 release) or by virtue of disappearing companies (SRM source & documentation disks for OEMs, various random workstation documentation and programs that don't necessarily made it to bitsavers, things like that)
UEFI is just a standard interface, not an implementation of a bootloader. This enables multiple UEFI compliant implementations as well as an easy way for OS to support all UEFI based bootloaders without needing to coordinate with the owner of the bootloader. While I'm sure most would agree the UEFI interface may not be ideal, it has a lot of industry momentum, and is therefore probably the best option to get behind. There are a lot of players in this space (mostly hardware vendors) and coordinating anything is very difficult and takes a very long time.