If it weren't closed and controlled by one large corporation's interests, there wouldn't be a monoculture, which would make this less severe of a vulnerability.
Of course, managing your own CA is a pain, but because of Linux's design an externally manageable CA system isn't practical. I believe Fedora is quite close to releasing UKI kernels that will let you import Fedora's keys dor upstream kernels, but those will likely break the moment you need DKMS for proprietory or too-bad-for-upstream drivers.
Please consider what it would take for me to reflash and install a new digital signature in the UEFI device driver for at least the following PCIe devices: (1) a GPU (2) a network card. It's a requirement that the device can cold boot after the reflash on an enthusiast motherboard that costs less than $200 retail with no other changes except the reflash, because that's what average consumers could do. If an average consumer could follow your procedure and not void their warranty, you win.
PoC or GTFO.
Loading custom CA keys into the UEFI store doesn't void your warranty and is available as a standard menu option on every UEFI setup screen I've seen. The key store can usually also be reset to accept Microsoft's keys again for when you want to run Windows.
As long as you know the password to your UEFI firmware setup, you can enroll keys or reset the key store. Of course this process is way more complicated than necessary (especially in Arch's documentation), but there's nothing preventing vendors like Canonical or Fedora from pre-signing kernels and drivers.
If you want to use your/your vendor's keys for existing drivers, you/the vendor can also have sign those files.
The only difficult step for the end user is enrolling the MOK key, which requires selecting the right option in the UEFI setup and a reboot or two. Anyone can set up a repository of presigned keys and kernels you can rely on, whether that's you or your favourite open source project.
The problem is a lack of availability because the people who would need this, open source enthusiasts running Linux or *BSD, often just disable secure boot entirely. Nobody has made a nice GUI for managing this stuff either, because everyone who messes with this stuff knows the command line anyway.
As far as I'm aware, the Platform Key is used to validate UEFI drivers' signature, so configuring Secure Boot as detailed in the Arch wiki will also provide you with the possibility to sign a UEFI driver.
I'm not sure if there are any open source UEFI drivers out there (I don't think anyone has bothered), but you could write them if you wanted to. Kind of like Windows drivers, there's just not a lot of interest in open source UEFI drivers. Secure boot isn't preventing you from writing your own drivers.
Customization of the POST boot logo image should be as simple as burning an image to a simple flash ROM which remains untrusted and data-only (no-execute) - the fact that performing these ostensibly harmless customizations will introduce a security issue just leads me to believe an intelligence agency is involved somehow...
I mean, it makes sense: one can probably convince the leaders of Hamas or Cuba that it's worthwhile to let the 14yo great nephew twice-removed of an inner party cadre member to replace their laptop's capitalistic imagery from ASUS/Acer/Razer/Dell with some JPEG with far more revolutionary appeal - they'd never suspect a thing...
This is definitely the kind of thing intelligence agencies look for but considering the half century of C programmers utterly failing at decoding files safely makes me highly skeptical that anyone needed to compromise all of these vendors.
Also, the Hamas thing is a bit of a tangent but given that Israel had over a year’s advance notice I suspect that elite hacking is not a prerequisite.
If you think compact C file parsing libraries containing vulnerabilities are some kind of conspiracy by intelligence agencies, I've got bad news for you about almost every operating system out there.
Hopefully in the future vendors will pick up languages like Rust with better memory management security (though any programming language can contain vulnerabilities, of course), at least for critical components like UEFI firmware, but as long as the current code bases are used, we'll have parsing bugs. These firmwares have over a decade of legacy at this point, and if they haven't bothered fuzzing up to now, I doubt they will do in the future, let alone rewrite their parsers to be safer.