Debian will still support UEFI, just not SB. I use Arch and UEFI. With a kernel supporting EFISTUB, a UEFI system can boot the kernel directly, without the use of a bootloader - it's awesome!
The UEFI spec pretty much says it must be there. What's your big problem with that, anyway? :)
It standardizes how to deploy a bootloader in a multi-boot friendly way without any cheating, tricks or risk of "competing" OSes stepping on each other's toes.
It significantly reduces complexity in all cases except for the simplest of them all, and even in those cases it represents a reliable standardization so it's possible for people (like you and me!) to inspect what actually gets booted, how and why.
Try that with ad-hoc MBR-written voodoo-tracks outside the FS and partitions. Now try it again as a OS-vendor who doesn't want to risk bad PR by accidentally overwriting existing bootloaders.
I honestly think this part of the UEFI spec is among those which makes most sense and is least problematic.
OK. That's your preference. But now consider this use-case:
You are installing a new OS, your first OS, on a blank PC, on a new disk. All is grand. No toes to step on. How does that OS deploy its bootloader?
You vote it should chose a simplistic way which is optimized for the single-OS use-case. It's primary objective: To save space, around 500MB of space, because you think that's something which matters.
But let's say you were actually planning for a dual-boot scenario. Now you're in the process of installing your second OS. How should that OS deploy its bootloader?
To determine that it is indeed a single-OS use-case (and this that it should use the single-OS simplistic approach, which differs from the multi-OS approach), it needs to find out if another OS and another bootloader is deployed. How should it know that? How should it be certain it doesn't overwrite something which doesn't belong to it?
And since we are now moving from a single-OS solution to a multi-OS solution... Should we migrate the existing simplistically deployed bootloader to a multi-OS config and wipe the existing single-OS configuration?
To put it bluntly: Should Windows move Linux's bootloader? Can you imagine the outrage? Any and every honest bug in such code would be deemed malicious by internet hotheads and be talked about for decades to come in threads filled with "M$".
And this is all getting very complex, very fast, isn't it? It wasn't so simple after all, was it?
With the EFI-partition there is a simple solution and simple answers for all those questions, at any point. Inspecting the state of bootloaders is simple. Deploying OSes is simple. Avoiding collisions is the default because different OSes namespace their bootloaders inside the EFI partition. Windows doesn't even need to know or care if Linux is installed!
Everything just works. At a cost. The cost of allocating a few MBs in the age when Terabytes rules.
And honestly, I find that a pretty good trade-off.
In the 90s I used the ibm? (I think) boot manager with 4 or 5 OSs, it took a one or two megabytes and worked quite well. That is more choices than are practical, honestly. And with VMs and containers less necessary than ever. (I do like GPT.) Doesn't have to be that small today, but shows what is possible. Xosl too.
Thirdly developing a completely new proprietary OS (uefi) when embedded Linux exists is about as cynical and wasteful as they come.
Unless you want to switch your HDD to another computer and have it boot properly?
And if there is a conflict (because now there can be conflicts. Oh boy!)... How should it be resolved?
Again, this is a source of even more complexity. All in the name of the "simple" solution you wanted. Just because a few MBs on disk.
Can't you see where this is heading? Do you really think this is worth all that extra bullshit?
While UEFI is clearly over-engineered in many aspects, what you're asking for is under-engineering. And we all know that leads to nasty stuff down the road too.
That's not what I wrote, pls read again.