For the same reason a website can't ask the browser to simply install another root certificate into its truststore: a browser simply doesn't offer an interface to do that.
The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore.
A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature.
All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.
That doesn't make much sense. You don't need any private material to verify signatures when using asymmetric cryptography. How's TPM useful at all if all it does is verify signatures?
The TPM had multiple functions, and for verifying operating system images indeed no private key is required. For that to work, it is merely required that the OS doesn't have write access to the TPM.
Private key material is required for remote attestation, which makes it possible to prove certain things to an external party, for example the exact identity of the TPM. This feature is much more questionable.
The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore.
A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature.
All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.