My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now. The biggest concern I have is around cloud, where many providers still don't offer UEFI support.
I was on the Fedora technical committee in the past, and if I were still there I feel like I wouldn't go for this now. But I've also been very marginally involved in Fedora in recent years, and I don't think I have a good sense of what the tradeoffs are here. There are legitimate points where it's reasonable to say goodbye to the past, and maybe this is one of them.
Drawing the line at 10 years old is ... way too close for comfort. I could understand to drop i386 because it basically amounts to another entire architecture, and besides it seems with i386 you are also generally RAM limited which makes it harder to use a recent DE.
But a 10 year old computer is perfectly capable of running even the latest version of the heavy-est DEs.
Also, "working UEFI supports" means working enough to boot Windows and not much else. Kernel bugzilla still has lots of UEFI bugs open for early UEFI firmware, and even not-so-early UEFI firmware (cough efi=no_disable_early_pci_dma ).
My current desktop's motherboard and CPU are from 2009. I have no idea if the MB supports UEFI; it definitely boots to BIOS by default. I've upgraded the storage, memory, and GPU, but there's been little cause to waste money on a new MB/CPU. But I guess I wouldn't install Fedora on this machine anyway, so shrug.
Eep! efi=no_disable_early_pci_dma only does anything if CONFIG_EFI_DISABLE_PCI_DMA is set, and distros should not be setting that by default (it's a thing that works Just Fine in theory, and specific implementations may fail hard with it - eg, if ExitBootServices() triggers a callback that assumes that a PCI device is able to DMA, things may explode). It's a useful security feature (I mean, I wrote it, I would say that) but it can break even if implementations follow the spec perfectly.
You (and they) forget the part where graphics cards play an intimate role in MBR or UEFI boot. And there still innumberable quite functional graphics cards that will never, ever, allow a system to boot under UEFI. GPUs are deeply integrated into the boot up process.
This is easy for IBM/Fedora to forget because GPUs probably don't matter much to them. They just take their intel integrated graphics on their workstation (or server) and go. And other linux devs are probably rich enough to buy a modern GPU.
But it is a huge issue and it'll not have become irrelevant for at least another decade. Not being able to boot MBR will break (and prevent) much more than the Fedora, LWN, or most of the threads here are aware of.
I have a UEFI system right here under my desk that provides legacy BIOS services for running option ROMs, video cards, SCSI host bus adapters, network adapters, anything. It even scans out their legacy video outputs in a little window. There's nothing incompatible between UEFI and legacy option ROMs. Perhaps you are thinking of Secure Boot.
Nope. I think there must be a miscommunication here so I'll be more explicit.
If you have CSM/BIOS mode on your UEFI default motherboard and you set it to CMB/BIOS mode of course you can run BIOS based video cards.
But if you switch your mobo to UEFI boot (say, because you want to run future Fedora, or maybe boot off an nvme storage device) you can't use your BIOS firmware video cards (unless, like some gigabyte cards they shipped for a few years with both BIOS firmware and UEFI firmware). It has nothing to do with secureboot or signing or any of that. GPU's are intimitely involved (INT_10h in BIOS and something cursed in UEFI GOP) in the first few operations on boot in both systems and the firmware on the GPU has to be able to fulfill that role.
So Fedora removing BIOS boot effectively removes the ability to use most video cards ever made. Anything designed before 2015 has a decent chance of causing trouble.
Actually you can, you just don't get firmware boot support. Plenty of those boards work just fine in linux/etc because they reprogram the entire board using AtomBios/etc when the ati/nouveau/etc drivers load. The Arm/PPC/riscv people are all running the same PCIe boards as everyone else, and outside of a few cases they are doing just fine not running the x86 option roms.
A lot of firmware supports using CSM to do GPU init and then providing UEFI interfaces on top of that. Of course, this is incompatible with Secure Boot.
In fact, you can't really run any other legacy option ROMs without legacy VGA support. You can run legacy SAS option ROMs for example and still do UEFI boot because of similar support for Int13, but to even run them require VGA text mode to be working.
The majority of x86 computers I have are BIOS only, only one of them is UEFI and I only have it because I found it discarded on the side of the road. I don't use the UEFI mode though, since my current install doesn't support booting in UEFI mode (no GPT) and wouldn't support booting in BIOS mode if I switched it to GPT and UEFI.
I was on the Fedora technical committee in the past, and if I were still there I feel like I wouldn't go for this now. But I've also been very marginally involved in Fedora in recent years, and I don't think I have a good sense of what the tradeoffs are here. There are legitimate points where it's reasonable to say goodbye to the past, and maybe this is one of them.