I don't do much traditional driver development (mostly USB related, at least when it comes to hardware). I know enough that dealing with the ARM ecosystem can be much more of a headache than in the PC world, for two reasons: diversity and more opaque specs. (Even if the PC stuff is proprietary, there's enough publicly leaked info to at least get started.) But ARM features are also often much simpler and straight-forward. If the documentation were always and completely freely available[1], then I think many developers would prefer dealing with ARM platforms than with PCs. You may be writing more drivers, but development would be more efficient and reliable and you could move on without having as much of a maintenance and bug-fix burden. It can be a worthwhile trade-off, and fits better with the open source model.
[1] I spent months trying to sign an NDA and gain access to NXP's iMX53 Security Reference Manual. After repeated back-and-forth with two NXP resellers, Mouser and Digi-Key, I just gave up.[2] I've heard of lone developers getting access to the manual, but they must be more familiar with the process than I am. Now I'm pivoting and have decided to use seL4 on PC hardware rather than bother with the TrustZone and the iMX53 crypto hardware, even though the ARM route would have been easier but for the documentation issue.
[2] I think it's NXP that kept dropping the ball, but I'm really not sure.
The culprit isn't UEFI, it's ACPI. That mess predates UEFI. Most operating systems don't really try to use UEFI features beyond the ability to manipulate the bootloader settings, and that feature is almost always correctly implemented. But it's impossible to find a consumer system with bug-free ACPI tables.
The UEFI implementation in U-Boot is tiny, and yet is enough to boot (both from local storage and network) and have a text console.
Most non-embedded board vendors do not reimplement UEFI. There's not much to get right or wrong. They just take AMI or whoever's private fork of TianoCore, tweak some settings and customize the GUI. (It is possible to screw up the GUI though: https://youtu.be/F-ndTMeRT3s)
As mentioned in other comments, it's ACPI that's really bad.
Though at least it's a standard! On ARM, you typically have to have a driver for every. damn. power. controller. Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)
I can't believe anyone would be thankful about ACPI. Is there a machine with ACPI that isn't broken in some way? My brand new Lenovo, which multiple sites have crowned the "best" PC laptop, ships with a LTE card that can't properly power down, and causes PCI-E ASPM to be disabled. Even Microsoft has f--ked up power management repeatedly in the Surface line.
Power management on PCs is such a disaster that it calls into question the very idea of doing power management for computers built out of mix-and-match components through standards like ACPI.
I'm not necessarily cheery about ACPI in practice, but ACPI & UEFI in theory provide some kind of substrate to manage the platform, that's not just whatever the engineers are some shop cooked up this time.
But having individual drivers per SoC in the kernel for things like power management still sucks.
In the case of the S3 sleep state, this is just sloppy decision making. Sure give us a new fancy, half sleep-like mode, but don't touch the suspend to ram, it's a feature that has value.