SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you set up an enclave you're effectively opting in to better security for lower performance. For instance, a lot of the early attacks were blocked simply by making the CPU flush its state when entering or exiting an enclave. Intel could do that because an enclave is meant to be hardened, whereas other sorts of mitigations at e.g. syscall boundaries hit tough performance/security tradeoffs that are very different in different contexts.

Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field.

For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.

Wikipedia shows a spate of speculative execution/timing-based attacks against SGX, as recent as 2020. something like 10 different attacks.

business-wise, I think Intel's decision to gatekeep SGX and require developers to buy licenses to get signing keys probably doomed it, along with how weird and arcane it was to develop for. but the security was not good.