Oftentimes, these tools are developed for much more complex sites than the people who author these rants have ever maintained. Of course it doesn't solve meaningful problems for sites that can be maintained by a handful of developers and whose feature set evolves slowly.
That's fine. Don't use them.
It'd be nice if rants like this also reflect on why these frameworks do exist. Then people would actually learn something.
Here are some of the tradeoffs I considered when evaluating JAMStack vs flask/jinja server side rendering.
1. Low latency interactivity unlocks all kinds of user interaction optimizations for us. The size of the initial download is amortized over hundreds to thousands of lightening fast interactions.
2. It's difficult to manage complexity around large html/css deployments, since CSS is a global namespace. Devs use all kinds of conventions for modularizing CSS. You can definitely succeed with these strategies, but when you're juggling tens of thousands of lines of CSS, it's a lot easier to solve these problems using a real programming language and its module system. We anticipated thousands of lines of CSS over time.
3. Immutability makes whole classes of race conditions unlikely to impossible. Do things still race in React? Of course. Are they vastly less likely to happen? Yes.
4. Managing interactivity through server-client interaction shifts a ton of complexity to the backend that the browser could otherwise handle. If you're designing a multi-stage form, for example, you often have to save incomplete user submissions in servers, depending on use case. Offloading this to localstorage on the frontend is a lot easier to author and maintain.
5. If you host your frontend statically on CDNs, that's several orders of magnitude less traffic you have to scale your web servers for. The vast majority of my company's traffic is handled by Cloudfront, making our operational footprint tiny.
Are there also reasons the modern stack sucks? Yes.
1. Configuring react and webpack is incredibly, incredibly hard. Webpack exposes a vast array of knobs that most applications don't benefit from tuning.
2. Time to first load is absurdly slow and server side rendering is, again, very complex to implement. React is not the right choice for a blog or anything that is sensitive to bounce rates.
3. MUI's documentation and APIs are painful, as OP notes.
For these reasons, and because most of our application was interactive, not read-only, we went with JAMStack.
I definitely think there's a place for the traditional HTML/CSS/jQuery stack. Read-only sites, for starters, with limited feature complexity. Everything I've built in the last several years has grown in complexity and features at a faster-than-linear rate, however, and these new technologies make managing such codebases vastly simpler.