That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub.
On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct.
Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cry...
One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure.
Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.
It also isn't something that any software can use to just spit out the secrets it stores. The whole point of the TPM is that it will only release information if the measurements of the system match. IE, if I chainload grub->window that will cause a different measurement then it the system just booted windows.
But again, secure boot will only run signed images, but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.
No, it implements the verifier API which needs to be disabled for this to be true. This should not be the case for distributions utilizing the shim+grub setup (Ubuntu/SUSE/Fedora/Debian/etc)
I think the critical point is that the measurements are made by the CPU, not the TPM. Malicious code running on the CPU can tell the TPM whatever it wants to tell it. The TPM is notionally just a peripheral hanging off a low speed serial bus. All the TPU can do is watch the sequence of measurements being fed to it, and decide whether or not it looks suspicious. The idea is that everything is chained off of an initial known to be trustworthy state. The initial known state is provided by boot-up, where the first code to run comes from ROM or an EEPROM or flash chip. Secure boot is the mechanism by which that boot-up code can load more code off a storage device and authenticate it. Secure boot is literally what keeps the system secure while booting, before the TPM is configured.
Your point about grub being insecure in some ways is likely true. It's been around a long time, and existed before secure boot. The grub image itself being on an unencrypted partition doesn't matter, though, because it is signed; secure boot won't run it if it isn't authentic. I don't think the configuration matters much either. Grub can be configured to give the TPM a measurement of what it's actually loading, i.e. the kernel and initrd and boot options. The TPM can then refuse to give up its secrets if that measurement doesn't match what it expects.
Booting is complicated, and when you're mucking around with stuff like grub, it's easy to accidently break the chain without realizing it. There's a reason why corporate IT tends to prefer Mac, Chrome OS, or Windows based computers; it's easier to say that the system is properly secured through boot until the corporate spyware is running. As a practical matter, though, a broken link or two doesn't mean that the whole chain is useless. Stuff like secure boot, TPM, etc. all decrease the attack surface. You shouldn't store nuclear detonation codes on a computer you know isn't perfectly secured, but it's probably fine for your tax return from 2015 and meme collection; no one's going to bother individually targeting you.
In such a case you can just disable it as it doesn't provide anything than additional hassle.