Allowing users to work when their mobile signal is spotty is pretty good UX for those that don't deal in a office cubical or wfh.
Yes you could argue that native mobile apps have that covered...
But should it be that you have two proprietary "standards", and only those two? For "trivial" apps that are just data entry/query?
Why do I need 124mb for the app code alone of Twitter, when the web version is closer to ~7mb (ang don't start the argument about 7mb being obscene for a website, please. we're discussing a web APP, not grandma's cooking blog).
Plenty of sites are still on the "Linux, MySQL, SpringBoot, and HTML/CSS/JS" stack or equiv. We just have tools now that let us add "works while you're on a train where the internewt is unreliable" to the featureset.
Don't get me wrong. The world still uses the technology you mentioned at large, but the industry has in-fact built upon and grown alongside older technology.
In general, the whole rich web app space reminds me of the "You're not making Christianity better, you're making Rock'n Roll worse" meme.
But seriously, I'm okay with working with SB when I have to, but quite often in those situations Java wouldn't be my first choice, and it's still all the putrescence of proper Spring underneath. A framework for a framework, with a bit too much magic for me. Explicit is better than implicit.