Sorry, that wasn’t at all the context of that. Read my message again. You were talking about ways an evil maid could do evil things by exploiting GRUB2’s extra code, which is precisely why the streamlining.
You are also mixing up UEFI and Secure Boot. You can keep using grub-efi* (the unsigned ones). They won’t be touched. This is purely about reducing attack surface, so evil maid can’t exploit grub in ways described by you, among others. You are essentially saying that there are plenty ways around Secure Boot with GRUB2 (signed) is right now, while simultaneously claiming nothing can be done about it. Well, you’re wrong. Also, encrypting /boot is not a security measure, because said evil maid could just exploit said extra code in GRUB2 to install a Trojan Horse to grab your encryption key.
If you are not worried about evil maids, e.g. when using a stationary PC or server which is secure from tampering by random strangers, then Secure Boot is pointless and you can just disable it.
But there may be other Ubuntu users who actually need SB to work as intended. If you had read the whole thread, of which I am rather doubtful, you should have found that I’ve even suggested looking into systemd-boot, because it looks like a better fit for SB, like sd-boot for UEFI+SB and grub for plain UEFI, BIOS etc.