And when it comes to open firmware standards, why didn't Intel go with IEEE1275 but invent its own? firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard.
New Win8.x machines are required to boot using UEFI, and OF on x86 was never popular anyway. To show some of the harms this situation have caused BTW, LKML has a lot of posts about various UEFI firmware bugs, and remember that Chrome OS is based on the Linux kernel.
No moving parts means no worries - that's a lesson the UEFI architects never understood.
So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design).
And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so.
Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design.
UEFI is that bad.
Combining coreboot and Tianocore can build an open source x86 UEFI. But unless you need the network boot feature, UEFI is a waste of time and space.
It's good enough for KVM (that Linux virtualization technology), which boots Windows all the time.
There is also talk, and perhaps actual implementation, of TianoCore running on top of coreboot.
SeaBIOS is also used by VirtualBox, and probably Xen as well.
But seabios is much, much easier to integrate because it has fewer moving parts