The secure boot vulnerability was shown on a lenovo laptop. I’ve found welivesecurity.com/…/when-secure-isnt-secure-uefi…, but I’m not sure whether it’s the same thing I was talking about. The attack abused the fact that the TPM chip was outside the CPU so it was possible to read the keys in plain text by just putting a clip on the chip. The laptops in the ESET article seem fairly new so I would expect them to have TPM inside the CPU.
I recommend reading “threat model” page on Heads OS’ website. Secure boot can be disabled in the UEFI settings which can be accessed by unplugging the CMOS battery to reset the UEFI password. Undoing a few screws takes a few seconds so the bottleneck would be how fast you can upload your fake login screen onto the drive.
Servers can use FDE obviously but using them becomes highly inconvenient if you enable that. In order to boot you need to decrypt the drive but how are going to connect to the server if it hasn’t booted yet? One solution is to only boot the server when you have local access. The issue rises when your server crashes. Alternatively you can either start sshd early in the boot process at which point it isn’t really FDE or have some kind of KVM which just shifts the issue to a different device.