Obviously it isn't in everyone's skillset, but if you have the means there is nothing preventing you from generating and using your own key.
Honestly it seems like a good basic security precaution, not only to prevent against leaks like this, but also to counteract any backdoors (although kind of a moot point with chipmakers).
1. some EFIs are broken in ways that make using private platform keys hard or impossible
2. there are PCIe cards which need option ROMs to be executed (most commonly that dedicated GPUs), this ROMs are not always but often signed by one of the Microsoft Keys and removing it from the trust db will prevent the ROMs from running and lead to all kinds of problems, e.g. not having any video and in turn not being able to undo to EFI setting/disable secure boot. You can make sure the specific ROMs are whitelisted, but then you need to be very very careful about e.g. graphics drivers updating the GPU firmware and similar. And putting the right data in the trust db isn't easy either.
If you're using a TPM for Secure Boot, you can use the commands in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.
Because of this validating option ROMs is _very_ important to a point some would argue it's more important then validating that e.g. your Linux kernel has not been modified
Honestly option ROMs IMHO should not exist in the way they do (for security reasons), but they outdate secure boot by quite a bit and like many of this "old legacy features a lot of things depend on" are just really hard to get right of.
Through without question the design this ended up with has a terrible UX.
But most laptops with a reasonable EFI implementation and no dedicated graphics card do luckily not have option ROMs (through their firmware update tool might have something similar, but you can just not use it).