A contrary opinion:

I've done a little of both, first learning to write raw HTML in Perl and then (a long time later) becoming a frontend-focused JS dev. I loved Angular 1 (it was kinda like an early Next.js without the SSG), and for all the hate it gets here, I learned to love the actual Next.js later on too.

I've worked on a variety of small code bases, and one hard truth I've come to learn is that everybody loves their own homebrewed code, and hates everyone else's.

The thing about the big frameworks is that they at least follow some basic testing & documentation procedures, which homebrewed stuff very rarely does in the real world. Homebrewed code can be a real headache for anyone else to maintain unless you go very far out of your way to abstract its functions and document the hell out of everything (in which case, really, you're just writing another framework).

If you don't do that and just code like a regular person (i.e. make a website for your own one-off use instead of for long-term maintainability by other people who you'll never meet), it gets tricky for anyone who inherits that. It's fine if you're a founder-operator of your software company and plan on sticking around for a while and can guide newbies around your codebase. But every job I've gotten was because someone else quit their job, leaving behind a messy codebase that I was tasked with maintaining (and usually rewriting in whatever the popular framework of the day happens to be). Something like that takes days of reverse engineering to even begin to understand how it works (especially if they invented their own routing/templating/caching/building system, or even worse, if they decided to tackle state on their own, by injecting things into `window` or modifying the DOM with data attributes and such). Along the way I'll often find a mix of clever hacks, ugly hacks, and just plain mistakes that they made because they thought they were being clever. And mind you, I'm not an especially good dev, just a mediocre one who's had a few decades of experience. Newbies and juniors especially struggle with a codebase like that.

By contrast, the main advantage of adopting a popular framework isn't necessarily that it saves you a bit of time over writing your own abstractions (which it does), but that it's really easy to get new devs started on it. There are standard conventions for most basic things, and when in doubt, they can look up the documentation and examples on their own. A relatively junior dev can find the right file in a few minutes, start editing it easily since all the built-in functions are documented and tooltipped (either in Typescript or JSDoc), there's built-in tests and warnings and a preview server with hot reload, etc. The devex is usually far superior (nowadays, at least... wasn't the case 5-6 years ago certainly), especially compared to a bunch of homebrewed code that's separate from the local hosting environment, whose creator gave no thought to reproducible hosting/local dev environments.

I also don't agree that frameworks are shorter-lived than web standards. I've been a web dev since the 1990s, and have never seen web standards really be, well, standards. They've always just been mere suggestions/guardrails at best, and it's the big browser makers who dictate what works and what doesn't. Back then, we had IE and Netscape and Phoenix, ACID tests for CSS, and various incompatible frontend languages (VBScript, Javascript, JScript, Java, Shockwave, ActiveX, etc.) These days we have CanIUse and polyfills, but the bleeding-edge stuff is still incompatible, with Chrome basically dictating what is "real" and Safari and Firefox playing catchup eventually, sometimes, but not always... like WebGPU, JPEG XL, or WEBP/AVIF a while ago. The frameworks account for things like that (among other things) and transparently polyfill them and provide higher-level abstractions. And keep in mind that the standards body itself was completely abandoned: the W3C, after many failed attempts at improving web standards, gave up and went on to more esoteric things like the semantic web, leaving the "real" de facto standards to be dictated by... well, the browser makers (via WHATWG). So we're right back where we started, with browsers dictating what works and doesn't work on the web, and each browser having their own interpretation.

By contrast, how long has Wordpress been around now? Or MediaWiki? I was paid to maintain Drupal just a few years ago. jQuery is still popular, despite whatever ECMAScript version we're now on. Rails is still around in that long tail of smaller company backends.

I would 100% bet on popular frameworks sticking around longer, being easier to maintain, and and usually being easier to upgrade later, than some individual or organization's homebrewed code.