The problem with STM is A: You can not retrofit it on to an existing language and B: The language you build to support it looks an awful lot like Haskell, particularly the careful separation between pure and IO code. And as of 2022, most programmers are not willing to program that way.
I do a lot of concurrency stuff, and my go-to is one form or another of message passing. It isn't a miracle cure, but it turns the exponentially complicated issues with lock-based systems into polynomial ones, and that's at least something you have a prayer of managing. They compose better. I'm not sure I'd say they compose well, and someone may yet find an even better model, but they compose better.
(STM doesn't seem to be that model. As the transactions inevitably get larger over time they start getting complicated.)
If SOLID principals apply in spades to regular code, then there's a power law for concurrent code.
When Simon Peyton Jones was working at Microsoft Research on Software Transactional Memory, he prefaced practically every video/interview with this uncomfortable fact. Given the lack of traction, I can only assume that some of the corner cases of STM proved to be intractable, and my read on the domain is that borrow semantics are trying to arrive at a similar place by different avenues. I'm very interested to see 1) how far borrow semantics get, in the same way that type inference simplifies generics, and 2) what someone tries next, particularly if it involves synthesizing elements from different schools.