> for consumer Windows devices. Microsoft foolishly doesn't enable Bitlocker on them
Actually, Microsoft enables Bitlocker on many if not most consumer devices. For example, I have not been able to find a laptop without Bitlocker enabled by default since the Windows 8.1 era. Even home editions of Windows enable bitlocker by default, even if they don't call it Bitlocker (they call it "Full device encryption" or the like). On desktops the situation is the opposite -- until recently, most desktops didn't even ship with a TPM at all.
Nowadays TPMs are a requirement for Windows 11, so devices with Bitlocker disabled by default are going to be a minority.
> I don't see the point of keeping it enabled on Linux if all of its protection can be disabled by editing a file on /boot.
That's not true -- if a distribution is shipping a signed bootloader binary, then there should be no way to use that distribution's bootloader to run an unsigned binary. In fact, it would be considered a security vulnerability and the corresponding bootloader binaries would be blacklisted by Microsoft. It has happened in the past: https://www.suse.com/support/kb/doc/?id=000019892 . The default behavior of most distribution's GRUB2 (and specially whenever it is pre-enrolled into a signed shim) is that when you boot under Secure Boot it will check the signature on any UEFI executable, GRUB module, or Linux kernel you try to boot, and refuse to boot if it is not in the (UEFI firmware/shim) whitelist.
> Linux needs better secure boot key management features if it's serious about making secure boot work.
Linux already has multiple secure boot key management facilities. And then there's shim.
But in any case, the problem is that Microsoft itself should be required to face these problems; under no circumstance should it be that by default MS gets their signatures to work for free but everyone else needs to have extra UI to manage them.