SGX was designed from the start on the assumption that there would be bugs or people would find clever unanticipated attacks, so it has a games console-like resealing procedure that lets the platform be fixed in place via firmware and microcode updates. SGX pre-dated Spectre, so those assumption were proven true, and the platform was resealed a bunch of times.
Is this a success or failure? The article takes it as obvious that it's a failure. But if you judge a general purpose computing system by the standard of "did it ever need to be patched" then there has never been a success. Clearly that can't be where the line is drawn.
An alternative place to draw the line might be whether the system provides the needed guarantees when fully patched and there are no known bugs. According to this standard, SGX is a mixed bag. The original SGX implementation fully took hardware attacks into account including on DRAM chips. Later versions were deliberately weakened to try and find product-market fit, as developers were unable to handle a programming model more complex than "boot an entire VM with our app inside it" (and frankly even then weren't able to get it right, I've seen so many botched RA implementations). But you hit hard physical limits: making untrusted DRAM secure trades off against making it large. Developers reject anything that requires them to conserve RAM, and so the original SGX design died there.
This was arguably not Intel's fault. A few hundred megabytes of RAM was sufficient to achieve many important security goals with the original SGX model, but developers just don't care enough to do learn a new programming model or paradigm. It's easier to just trust the cloud providers to not peek, like everyone else does.
AMD SEV ended up getting more support from the cloud vendors because it required less work from developers, but AMD's implementation was much worse than Intel's was and spent much of the time I worked on this stuff in an entirely broken and un-resealable state.
SGX is one of those technologies that was maybe ahead of its time. Privacy tech in general is a hard sell because there are very few scandals where tech firms leak data, so blocking that possibility via more programmer effort was a hard sell in a world where skilled programming time was scarce. Maybe AI changes the game here, hard to say.
I don't think the article is saying "don't use TEEs", more like "don't rely on TEEs". If you have a system that's already secure and you run it inside a TEE, it's an extra layer of defense in depth. Great. If you have a system that's only secure because it's in a TEE, then you don't have very much security at all. If a forged attestation from an arbitrary machine breaks your entire security model, you're in especially hot water.
It is obvious to us to just "don't do that", but there seems to be a general lack of awareness of the true security properties of TEEs, and people keep building bad systems on top of them. I think the article is doing a good job of communicating the actual security properties.
And of course at the heart of every credit card is a very small TEE. Not a general purpose computer, sure, but still a chip that can have bugs or be physically attacked. And it protects money! Yet the system works anyway.
Our industry could do a lot of good if it just embraced TEEs a lot more, even if they sometimes needed patching or even needed physical replacement. There's lots of ways to do defense in depth, or just accept the business costs during a degraded period.