I think part of it is bandwagoning, everyone jumping from one fashionable tool/framework to the next, doing so very quickly and repetitively from like 2018-2022 or thereabouts.
Thankfully it's slowed down somewhat since then, with the frontend industry mostly standardized around Next.js for big apps, Vite for sites that don't need much serverside rendering, or Astro for simple blogs.
As for whether there are results to show for it... well, now you have some pretty cool web apps like Figma, ClickUp, Felt, OpenSolar, Photopea, Codesandbox, etc. that actually use interactive clientside Javascript to its potential. That would've been more difficult with a server-only stack that renders and sends HTML over the wire, or with manual AJAX fetches. Is it possible? Yes, just harder to reason about -- and importantly -- harder to divide up across multiple developers or teams.
What Jamstacks (Javascript, API, Markup) are really good at is allowing a cleaner separation of concerns, where one team can work on the backend API and another can work on the user-facing frontend and a third can work on editorial content, all without stepping on each other's toes (but with frequent communications and collaboration).
Are they misused sometimes? Yes, often, I think. A lot of sites don't really need to be in Next.js or a Jamstack at all. Wordpress would've worked fine. Wix would've worked fine. Anything would've worked fine. But our industry chases trends, beginners are taught what's fashionable, and then when they're no longer beginners, they try to improve the tooling, eventually some of it gets good enough to start a new trend, and the cycle starts anew...
------
<Long rambling anecdote>
On a personal note, I think a part of it also might be the nostalgia of days past that weren't really all that simple. Maybe we just forget how complicated it used to be?
I started web dev back in the 90s, hand-coding HTML on a 28.8k modem before Javascript and CSS were invented.
My first full-time permanent job was as a full-stack PHP dev, where I had to manage not just the HTML and the PHP templates but also the bare Linux VM under it (this was before EC2 became really popular, so we still rented shared metal from a data center) and everything above it. I had to learn and implement every OS package, every daemon from redis to varnish to monit, every row in every database (we used MySQL for most things, Postgis for geo stuff, Filemaker for other things), every interop script with other parts of the business (sometimes in AppleScript, sometimes C#, sometimes a Bash script, sometimes some Excel macro), every SSL cert and DNS and SPF setting, every PHP and Varnish and Apache option, every MySQL and Redis clustering/slaving/failover setup... long before ever touching the HTML.
Then on the frontend side, we had to hand-code every basic JS interaction from the cart total calculator to every AJAX fetch from the database, all while screaming at the then-primitive CSS and trying to massage it to work correctly across Firefox, Chrome, IE, Safari and all of their rendering quirks and and CSS and CORS bugs, while juggling more complicated functionality across several versions of jQuery and a horrible matrix of JS features supported or not by different browsers, all while phones were beginning to become more and more important but best practices and standard UIs weren't fully developed yet.
I don't think there was anything simple about that stack. Every single layer of it had like a hundred different failure modes, all of which compounded exponentially with every other layer, and there were a lot of layers. When something went wrong, it was always my job to figure out where in that maze things went wrong. There wasn't really such a thing as a frontend or backend dev yet, you were just a web designer, and everything from the graphics to the code to the server was your responsibility, whether it's a GIF alpha transparency or SVG rendering issue or a cache invalidation bug.
Fast forward a decade or two, now the web landscape is very different, but a `npx create-next/astro/vite-app` will get you a functional local website in under a minute. Two or three clicks will deploy it to Vercel or Netlify in seconds. Databases can be similarly configured and deployed within a few seconds, if you need one. I can make an interactive dashboard in half an hour, polish it for another, and have it ready for users in half a day. That sort of productivity was never possible in the old days. Part of it is the growth of managed higher-abstraction services (i.e. they took the legacy clouds and built value-added abstractions over them to create things like Vercel, Netlify or even just DigitalOcean and Heroku), but the JS framework race did yield some useful (if messy) outputs too.
You can still make websites the old way if you prefer. But coming from Perl, PHP, and Visual Basic, I taught myself Javascript and React over the course of a few weeks. Once I got over the initial learning curve, it was an incredible improvement over the old ways, at least for frontend work. Once you start being able to compose pages out of real components, serverside templates and string replacements and such will never be enough again. Typescript moves the error-checking from runtime to write-time, vastly simplifying the debugging process. Modern IDEs are an incredibly powerful tool compared to the old text editors and basic syntax highlighting. Hot reload and built-in preview servers make any changes go live by the time you can cmd-tab back to the browser.
The developer experience now is sooooooo much nicer than it used to be, if you know how to use the tooling.
The UX, not so much... but that's because most of the industry thinks of the user as the unwitting victim to be productized and milked, not as the customer :( That's not really the fault of the frameworks, but company business priorities.
</anecdote>