In practice you have to enrol your own MOK if you want to use the nvidia drivers, or v4l2-loopback, or virtualbox, or a bunch of other things - so unlike on Windows, it doesn't give you any great OS integrity benefits.
You want those modules signed by someone like Canonical, so you don't have to mess around with a MOK? If you use Ubuntu Core they'll be happy to - for about $100,000 per year per module.
Automatically unlocking hard drive encryption is less secure than just typing in a password at boot.
No OS-independent way of confirming the user's presence means it's less secure than a Yubikey.
No iphone-style activation lock, so it's useless as a theft deterrent.
No xbox-style main memory or system bus encryption, so no protection against evil maid attacks.
Too slow for servers to offload SSL or disk encryption to - so all the important keys end up being held in memory anyway.
The spec and interface are complicated as hell, so you know there's no chance this stuff is bug-free. You want a command line tool? We've got 99 command line tools. Literally.
The foundation of its security is the code of your system's BIOS, which we all know is some of the shittiest code out there.
So the TPM offers a hair-trigger system that'll destroy all your data if your BIOS vendor messes up and miscalculates a PCR value. The security benefits you get in return are pretty minor.
You can have arbitrarily complex TPM authorization policies for unlocking storage keys. You can have it be that the loaded firmwares and OS are trusted and (or or) you have to enter in a passphrase that only the TPM can verify, and/or you can have a recovery mechanism so that if some firmware got updated you could use a smartcard or whatever to authorize moving on anyways. So, while OSes that support TPMs for storage key recovery generally have -as you say- hair-trigger policies, that's not TPM's fault but the OS's, for they could develop much more interesting policies.
Assuming you'll use LUKS for drive encryption, you can have several key slots that all allow unsealing the key to decrypt the drive.
1. You'll have your master password, for which it asks when you first create it. You can make this absurdly long and consider it'll be used as a last resort (say you've lost everything else and your computer is broken - you only have the drive left).
2. You can then add Windows-style auto-unlock with the TPM. It works with systemd. You can of course choose whichever registers you like, the correct TPM device if you have several.
3. If you're somewhat paranoid, you can have it ask for a PIN. Just add --tpm2-with-pin=true to the above.
4. What if this is an external drive and / or often change your UEFI settings yet still need a quick unlock? Luckily, you have a FIDO2 device, so systemd's got you covered:
--unlock-fido2-device=auto instead of the tpm2
5. You can probably combine TPM + FIDO2, I've never tried it.
edit: it should be noted that even on Windows, there's a recovery key which allows you to unlock bitlocker if the TPM was cleared. It's not clear what the poster above said that the data would be nuked (unless, of course, you only count on the TPM and don't save that key somewhere).
Not the OP but just anecdotally, last time I looked into enabling secure boot on my X1 Carbon there was an advisory from Lenovo that enrolling your own keys made it possible to brick the machine
Can you elaborate as to what is foolish about using a TPM?