given that Secure Boot prevents any modification of your computer’s boot chain

Secure Boot does no such thing. All it does it require that everything in the boot chain is signed by a trusted cert.

Binding TPM PCR7 to FDE (or more brittle options like 0+2+4) is really what protects against boot chain modifications but that’s another topic.

Disabling SB to install the distro, then re-enabling it once installed with either maintainer-signed shim or self-signed UKI/bootloader is perfectly fine.

You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.

If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.

Finally, if an attacker or malware gets root, FDE isn’t protecting you either.

Yeah this is an issue but not a big one. Most distro’s installation media don’t use shim so you have to disable SB during install anyway.

And installing the 2023 KEK and db certs can be done via firmware without much trouble or you can use sbctl in setup mode which I believe has both the 2011 and 2023 keys.

If you dual boot Windows you’ll want to update it to the new bootmgr signed with the 2023 keys and add the 2011 certs to dbx to protect against BlackLotus or let Windows do it via patches+regfixes.

Also know that any changes to PK, KEK, dB, or dbx will change the PCR 7 measurement so handle that accordingly if you use TPM unlock for FDE.