Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.
You need to compile a device tree for every single device you want to support individually, whereas x86 has ACPI to avoid that mess. ACPI is its own mess, yes. And UBoot is great. But it isn't a standalone replacement for a unified firmware interface/"BIOS"/whatever.
It's basically the same solution just in a different format. Device tree specifies device types while ACPI specifies the bytecode to interact with them, but the idea behind both is the same: the computer firmware tells the OS how to interact with it. It's been a slight success in both forms but not nearly as good as you'd hope it to be. The real problem is that nobody's testing all the firmwares and OSes for compliance so lots of devices ship incorrect data in firmware and then the OS has to patch it anyway.
Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.
Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.
When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.
