And given that it's done on memory (flash, that'll persist over reboots, windows reinstall and even hdd and sdd replacement), it wasn't done by trivial scriptkids.
Expect more tpm-like things "to protect you".
I mean that's pretty obvious given that we're talking about APT41.
Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..?
Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it.
In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.
Essentially your proposition comes down to 'no BIOS updates. And that has it's own problems, from a security pov and from a manufacturing recall pov.
Now that means normal users and IT depts can do all the updates they need, but if you have a need for your own private key you can do that too (after physically touching hardware).
Oh and for bonus points, a motherboard switch can enable the keyboard on a physical designated USB slot to be able to authorize a cert modification. So you get convenience of not having to open the system, or if you want additional security then open the case and remove that jumper.
I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. I've also experienced UEFI conflicts(?) loading linux to new boards that took forever to sort out. It seems BIOS development has not progressed as well or far as one might expect, but that may just be me and my klutzy bad luck.
My experience with BIOS updates has been mixed.
The first time I did a BIOS update, it added an option to tell it that the HDD connection had 80 wires instead of 40 wires, which enabled a faster transfer mode. The second time I did a BIOS update (on that same machine), however, it made the realtime clock lose touch with reality, apparently running twice as fast, so I had to revert this update. That put me off from doing BIOS updates for a while.
My latest laptop can be updated through LVFS (using UEFI capsule updates), and it's new and under warranty, so I decided to risk it. One of the first BIOS updates I did made, according to its release notes, an important-looking change to the battery management. Some time later, the laptop started crashing randomly (the crashes happened when the display turned off, but not every time). After a lot of searching, I found out that a later BIOS update made some unknown change which causes these crashes, unless you add "i915.enable_dc=0" to the kernel command line.
For now, I'll keep risking it (at least while it's still under warranty), and hope no other obscure BIOS-update-caused bugs happen (and I'll probably keep using "i915.enable_dc=0" on this laptop forever, since there's no way to know whether a later BIOS fixed it).
Enabling it in a machine-controlled menu that can't be navigated except by the physical keys might be better
You need both.