Same - I had the unfortune to do a brief contract on a mulesoft mandated project. It was unpleasant to say the least. The UI was also nearly useless, you had to drop to code to do anything meaningful. But the company paid a lot for it, so we had to use it.

Can you explain? It's being pushed heavily as an api spec, api catalog and middleware, and it's notclear to me why we really need it.

A huge part of the benefit of software like Mulesoft's is being a common standard. If your the type of company that will have 50 developers working on your ESB and services that's big. So is the expectation that in 30 years you can hire a new batch of developers that will quickly grok your ESB because Mulesoft will still be a thing.

Mulesoft does have a lot of cool functionality, but my impression is that unless you are the type of organization with dozens of systems, decades long timespan, and dozens of developers that Mulesoft isn't worth the money.

I think microservices obviates ESB. If you have a legacy system that you can't replace, build a shim layer. Or, better yet, take the money you had allocated for building an ESB and spend it deprecating your legacy systems.

What is an ESB if not a collection of shim layers? What you said in the second sentence is one of the purposes of Mulesoft. Creating a unified and consistent shim layer for all of the legacy systems you can't replace.