Everything you say is true. It would still be better for systemd to mount that filesystem read-only, and for the few (root-only) utilities that need to write to it to remount it read-write, write to it, and remount read-only.
Another reasonable option would be for a distribution to include SELinux policies that allow only the blessed tools (grub-install, systemctl, etc) to write to that filesystem. It would be a big change, though, because most distributions leave root and normal user logins unconstrained.
Except you only say this in hindsight. When developers were adding the efi mounts the only sane and reasonable assumption was "the bios is providing us write access to a table in its internal memory, this must be configuration data unrelated to the actual boot process and only needed for communication of data between bios and os".
In hindsight you can say "we should have mounted efi ro and made our efi tools much more complex so they can remount it rw write to it and then remount it ro again" but that is asking the systemd and efitool developers to have been prophets that motherboard firmware makers would be so disastrously inept and stupid they would put essential parts of their boot process in a shared variable table with the OS.
Its like saying you cannot ever introduce a memory clear into a GPU shader because you might wipe the firmware and the GPU could explode when its fan shuts off. You have to have the reasonable expectation the API you are working with is conforming, and when it is not you need to raise hell about it, and in the short term introduce the work around until the upstream problem is resolved.
The issue here though is that the upstream problem is proprietary farmed out awful firmware that restricts your freedom and bricks your hardware because nobody can audit or fix its terrible design.
Oh, no, I'm not saying what they did wasn't reasonable at the time, nor am I saying that the blame doesn't lie with the firmware vendors. Just that now, we know how bad the problem is, and a few possible workarounds.
Another reasonable option would be for a distribution to include SELinux policies that allow only the blessed tools (grub-install, systemctl, etc) to write to that filesystem. It would be a big change, though, because most distributions leave root and normal user logins unconstrained.