i've done a lot of work with Arm TrustZone, OP-TEE, and Arm Trusted Firmware. it's really nice. in Arm, the TEE is user-supplied, not vendor-supplied, so it gives an isolated execution environment for any sensitive code you might want to put in there. hardware peripherals (tzc/spu) allow you to designate certain bus addresses or memory ranges as "secure" during the early firmware initialization, meaning Linux (or whatever OS you use) cannot read or write to them. furthermore, unlike a TPM, the TEE isn't running in parallel on a co-processor -- it only runs when Linux yields control (cooperative scheduling) so it provides functionality without wrestling away control.
TEE is nice, but it's a pretty different use case all around, and the two are actually quite complementary:
TEE is effectively an execution environment below ring 0, together with some hardware isolation as you mention. But by itself, solutions based on it can't hold any trusted key material, so can't be used in attestation contexts.
TPMs and other types of secure enclaves or secure elements include secure storage and can come pre-loaded with external root of trust keys, which allows attestation (and by extension trusted computing use cases), but also completely local useful things like enforcing a PIN retry limit on usage of a hardware-stored SSH key.
But since TPMs are by design self-contained and don't have any input or output capabilities, mediating user access via a TEE and some minimal OS providing a user confirmation UI can be very powerful (for example so that malware can't lock you out of your own SSH keys by just entering the PIN incorrectly repeatedly).
