There's some link between secure boot and encryption.
If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.
Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.
Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
That's like saying there is some link between putting locks on your doors and setting up booby traps because if you don't lock your doors then you need to set up booby traps to prevent a thief from stealing your stuff. They're both trying to mitigate the same threat, but there is no connection between the 40 pounds of explosives I have wired to my front door and an intricate metal cylinder that can only be manipulated by another piece of metal in a specific shape.
No, it’s like saying there is a link between putting locks on your door and making sure the lock can’t be replaced with one that takes someone else’s key, or worse one that copies the key that’s put into it. The threat models directly overlap.
That's a good analogy to point out the weakness behind relying on encryption without secure boot but without going into the mechanism behind "making sure the lock can’t be replaced" people might incorrectly think "they're both about setting up locks and therefore they are linked" whereas "making sure the lock can’t be replaced" involves securing the environment that the lock is placed in, like "Make sure your hinges are not exposed so the door cannot be taken off its hinges from the outside and replaced with a seemingly identical door."
I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.
for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone to try that.
Unless you're using a SED, your EFI system partition is unencrypted. It would be trivial to build a malicious copy of popular open source UEFI bootloaders (grub, refind, zfsbootmenu, etc), and a bootable USB stick that scans your EFI system partition, replacing your unencrypted bootloader with a malicious one. This attack could then be applied by relatively unskilled people in a couple minutes ("boot this flash drive, wait until the screen says "done", power it off"). I hope your laptop is never out of your possession for more than a couple of minutes! (For example, the TSA at the airport, geek squad or other repair centers, or classically an evil maid).
