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.