Huh, wasn't aware of that. Reading through, it looks like this is just talking about Microsoft "Secured-core" hardware, which seems to be hardware specifically marketed to provide a Microsoft-certified boot chain.
I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).
It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate".
UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't.
This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick.
This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn.
There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.
I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).