Mulesoft, personally hate it - but it's definitely an option if you're trying to abstract out a whole bunch of legacy systems into clean APIs. Personally, I'd probably create some lightweight integration components in custom code (whatever language you like) deployed in containers on some scalable cloud platform over buying a chunk of enterprise middleware and trying to find the skilled resource to configure it. But, I don't think Mulesoft was a death knell here - merely a bit of a money pit. Same thing for AEM.
Overall, it doesn't look like they were choosing unreasonable tools to do the various things they wanted. e.g. they weren't trying to use Salesforce as a transactional database platform.
You could definitely pick a better stack, largely from open source, and deploy to the hyper-scale cloud provider of your choice - but I don't think the tech stack that's what screwed this project up overall.
- Monolithic Haskell web application.
- Very little JavaScript.
- Small team of people who know what they're doing.
- A couple of servers.
- Postgres and Redis.
With the remaining $31,500,000, I would buy weapons for Ukraine.
Here's what I'd choose as someone who hasn't done something like this in his 25 year career: Some front-end framework (is React still relevant?), Java/SpringBoot, Kubernetes/KNative, some mesh, some back-end mainframe integration with their legacy systems...