AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.
On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).
Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.
The firmware validates the shim. The shim validates the boot loader. The boot loader validates the kernel. The kernel validates the kernel modules.
Once you have that chain of trust, you can also add in other factors; encrypt your disk using a key, seal the key in the TPM, and lock that key behind validation of the firmware and the boot loader. Your system boots, those different components are measured into the PCRs, and if the combination is correct the key is released and your disk can be decrypted automatically. Now if someone boots your system using a different firmware or boot loader, the TPM won't release the key, and your disk can't be decrypted except by someone with the passphrase, recovery key, etc.
Without secure boot, you can't trust that any of those components aren't reporting falsified measurements to the PCRs, lying to the TPM, and getting access to the key to decyrpt your disk despite booting from a compromised USB drive. That, of course, means you can just encrypt your disk using only a passphrase that you manually enter, but for a lot of users (sadly) that's too complex and they'll choose not to use disk encryption at all.
Case in point, TouchID and FaceID are seen as alternatives to using a PIN or passphrase to unlock your iPhone, but they're actually meant as alternatives to not locking your phone at all - a way to make device security transparent enough that everyone will use it. Without a secure chain of trust from the firmware to the kernel, that's not really an option.