This statement is incorrect. There is only one way to SecureBoot cause a brick on itself, when you still are on BootROM MP51.0087.B00, the one without microcodes. Without microcodes, Windows crashes when saving the SecureBoot data, causing NVRAM corruption.
Outside this nowadays very remote scenario, the certificates, DB/PKs and etc, that SecureBoot saves inside the NVRAM don't cause the bricks, it's a red-herring for a more serious problem, the fragmentation of the NVRAM.
A fragmented NVRAM is what cause the bricks. SecureBoot just exacerbate the fragmentation since the certificates, databases, public keys and etc need considerable space. Once the fragmentation of the NVRAM "filesystem" starts, older entries are not being deleted anymore and when your NVRAM free space ends, you can't change boot disks anymore for example.
The first symptom that people notice is not being capable of changing the default boot disk, after noticing this very soon you will corrupt the NVRAM volume totally and you won't boot anymore. Another problem of a fragmented NVRAM is that you will erase and write sectors inside the SPI flash memory much more rapidly than what the hardware design expects and failure of the SPI flash memory for excessive erase/write cycles is now a problem.
So, it's not the SecureBoot data saved on the NVRAM, but the fragmentation of the NVRAM after 9, 10 or 11 years of usage.
SecureBoot certificates and etc are not what cause the bricks, it just exacerbate an existing problem.
