I think mistakes were made in not making it easier to adapt applications. (I disagree with Kenton's opinion this is futile, there are plenty of alternative systems which require bespoke apps, and if anything Sandstorm's biggest problem was not having
enough name-brand ported apps working on it people expected.)
For example, making external network requests from a Sandstorm app is hard by default. Years after it was "dead", Ian Denhardt wrote a simple drop-in tool you could include in an app which would use a conventional HTTP proxy to hijack the requests from the app and turn them into Powerbox requests. Even though it isn't "the best" way to do it, it is very serviceable and approachable to devs. I think it's something Sandstorm should've supported by default, to abstract away that challenge.
The funny thing is, Sandstorm is actually kinda a pain if you know the engineering you want to do but the platform restricts you from it: It's actually much much better at nontechnical users just being able to use finished apps. I don't think the "use Sandstorm as infrastructure" story is nearly as good. The original Sandstorm company wasn't running a lot of their own infrastructure on Sandstorm, and some of it that was required hidden hacks to work around some of the big ways Sandstorm isn't really designed for hosting websites.
I still don't think it's dead, but since everyone who still really wants to work on Sandstorm has bills to pay and jobs to do (and kids to raise), we definitely aren't moving super fast.
Where I do agree with Kenton is that Sandstorm really excels at running vibe coded apps, I've been playing with it, and found it very easy to get AI tools to fix apps up for Sandstorm. And of course, a sandbox that only runs when the user is interacting with it and manages all of the authentication for you is the safest place to run untrustworthy code that may have security or performance bugs.