I (see footnote) started off hating the UEFI because it changed everything for me and others working with bootloaders, but at this point I'm just ambivalent about it. It trades one set of problems for another. The biggest problem is with shoddy implementations and poor development/engineering practices by hardware and software vendors (I have some devices lying around from R&D that brick themselves if the ESP is erased; you can't even access the "BIOS" even if you remove the CMOS battery, can't boot from a removable disk, nada. Need to insert a physical, non-removable disk with an ESP compatible with that PC or mail it back in to the vendor for an RMA!)

That said, your argument really boils down to a straw man. None of your points are really in favor of UEFI and some show a misunderstanding of the previous situation. I really recommend anyone that wants to better understand the (traditional) boot process have a read of this guide we wrote, complete with flowcharts and breakdowns, entitled "Everything you ever wanted to know about how your PC starts up (but were too afraid to ask)": https://neosmart.net/blog/2015/everything-you-ever-wanted-to...

Anyway, to address your remarks:

1) I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk.

That has always been the case, at least any time in contemporary PC history. Ever since bootloaders grew past the 1 sector limit, the only code at the start of the drive has been a pointer (that can even be copied and pasted between Windows and Linux, etc. because it serves a universal purpose) that looks for and loads the first active, primary partition on the drive. That is where the actual bootloader code resides.

2) I can easily update, add and remove boot entries from the OS command line.

This isn't anything to do with UEFI either, it's just a matter of your OS providing an interface for doing so. Microsoft did that back in 2006 for legacy bootloaders with bcdedit (that's where our free EasyBCD tool comes in) and we've developed standalone cli utilities for doing the same for GRUB under Linux.

3) I can forgo bootloaders entirely and use Linux as UEFI application.

Sure. But that bootloader code has been integrated into the OS and the firmware. Really it's just reduced the abstraction and increased blurring between the layers. Makes it hard to swap out components.

4) I can use GPT and finally partition as much as I want.

GPT is independent of UEFI. Many operating systems support the use of GPT partitioning in a BIOS environment (see Windows and FreeBSD, until recently, FreeBSD defaulted to doing so. Not sure if it still does, would have to spin up a VM and check against FreeBSD 12-CURRENT). GPT is a partition management scheme, UEFI is a bootloader scheme that requires GPT (interestingly, while it requires GPT to be understood, it does not require GPT to be necessarily used and can actually function with MBR drives, though in practice this does not happen. Mostly.). In addition, the GPT spec is purposely backwards compatible with BIOS by reserving the first 512 bytes of the disk (where the 446 bytes of MBR bootloader code followed by the 66 bytes of partition descriptors would be located), which can be used to point the traditional "BIOS bootloader" to a GPT partition to serve as a shoe-in.

(I'm the developer of EasyBCD [0] and numerous other boot utilities that deal heavily with EFI/GPT dark magic [1])

[0]: https://neosmart.net/EasyBCD/
[1]: https://NeoSmart.net/EasyRE/