Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.
Then you can have ARM64 Linux which boots on anything what has UEFI, like today having x86/x64 Linux which boots on everything what has x86 processor inside under expectation that the mother board has BIOS/EFI/UEFI as well.
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.
Having UEFI in some form means you can just boot your preferred Linux installer and install to disk, much as you would for an x86 device, rather that needing to get a specific disk image and dd it to an SD card.
UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.
They don’t have exactly the same coverage. UEFI provides a standard set of APIs, some optional, some mandatory. It also specifies a boot path via gpt and efi system partitions.
A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.
Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).
Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.
Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.
Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.