Despite the bad press it's received over the years, SGX is a very solid design and works pretty well. Some of the papers presenting breaks turned out to be quite misleading when I looked closely at them some years ago. If you want a general purpose TEE then you could do worse than play with it.
Unfortunately it's not available on consumer hardware anymore, and in the cloud only Azure really supports it AFAIK. And you have to write apps for it specifically, and then you have to have clients that know how to do remote attestation and bind it to secure channels, and you have to program in a threat model in which rewinds are possible at any moment. This is very hard, and it turns out most people in the market don't really care about their data that much (are happy to share it with trustworthy institutions). So it never really took off. But the tech is decent.
Amazon has their Nitro secure enclave system that's pretty easy to use. IIUC its based on isolating the code that runs it and in it onto one core set aside for just that, possibly just when it's needed. Having the SE be easy to use is a key thing. Not that the Nitro approach extends well to consumer hardware (it doesn't).
The problem with Nitro is that a TEE doesn't really work if the adversary makes your CPUs.
SGX works, conceptually, because of the division of labor between Intel and the people running the machines:
1. Intel can't break into your enclave even by subverting SGX, because it doesn't have access to the computers (isn't your cloud operator or network admin).
2. The people with access to the computer can't break into your enclave, because SGX blocks everyone except the enclave owner and Intel.
With Nitro, Apple's approach and a few others the logic becomes:
1. Amazon can't break into your enclave even if Nitro has a back door because Amazon don't have acces.... oh, wait.
SGX is conceptually sound because subverting it at the design level requires the CPU maker and the cloud operator to team up against you. This could happen, especially if you use a US cloud and the US government gets involved, but the bar is much higher. And of course you can always choose to run the hardware somewhere the USG can't get at it, requiring a coalition of those two governments or providers
Governments as threats... that's way beyond what people who want DRM consider within their threat models. TFA was about TPM not being relevant to DRM.
For most public cloud users having to trust the cloud operator is just a fact of life. Even if the SE were strong up to but excluding collaboration of the CPU vendor and the cloud operator, the user would have to run most if not all of their code in the SE, which is one thing the SEs invariably can't do.
Unfortunately it's not available on consumer hardware anymore, and in the cloud only Azure really supports it AFAIK. And you have to write apps for it specifically, and then you have to have clients that know how to do remote attestation and bind it to secure channels, and you have to program in a threat model in which rewinds are possible at any moment. This is very hard, and it turns out most people in the market don't really care about their data that much (are happy to share it with trustworthy institutions). So it never really took off. But the tech is decent.