Earlier quoted context omitted.
A form with a logo... that looks consistent across most browsers, scales automatically between mobile and desktop user-agents, and already has all its sticky a11y metadata sorted properly, if they've picked a good framework. The gap between modern expectations and the bare-bones AJAX page is pretty wide these days. It would definitely be better if there were a way to side-load those libraries as a standardized strata…
To me what youre writing sounds like a parody given the context. And I feel like I could write a form webpage with a logo in significantly fewer characters than used in your explanation for why you need all that stuff. But this isnt my field of expertise so I'll have to take your word for it that you're not joking.
Doing a form that will do things people expect these days (client-side validation, formatting, error-handling and highlighting / locating fields with errors in them, auto-fill of addresses... What, you don't expect the user to type in a whole address without verifying it's a real address, do you, there's validation services these days!) is the kind of thing you may want a framework for.
This relatively simple "Contact us" form (https://aflcio.org/contact) loads nine custom fonts, JQuery, an email-decoder script from Cloudflare, and a host of other things. Why nine custom fonts? Because the AFL-CIO has a brand and they're not obliged to deviate from it just because your browser doesn't have the font they use, anymore than they wouldn't show their logo because your computer doesn't have the logo yet. Why JQuery? Probably because there's a button on the page that hides and shows a field, and even in The Year Of Our Lord 2022 those are still an absolute witch to write without bugs in plain JavaScript. The email-decoder script is, I think, self-evident; lets them save the bandwidth of rejecting your input if you put "no" as the email address. And of course, the tracking scripts because they want to know how people are finding the "Contact Us" form (are they coming in from the main page? Is there some specific page that should be answering their question that they're falling over into "Contact Us" instead? Are they coming in from completely outside our org because someone shared a deep-link on a political site and said "Go bug the AFL-CIO", because if yes they can use that tracking to pre-filter the messages they get from that entry-path and bin them all low-priority). I'm seeing some inefficiencies in the Inspector (it's loading some Android-specific icons, probably because it's not good about refraining from loading assets for its mobile layout), but a lot of that stuff I'm not surprised at all to see.
There are several driving factors underpinning this phenomenon. One is that frameworks are more flexible (per unit of code written) than bare-AJAX development, so there's plenty of "everything looks like a nail" thinking going on; once you've paid the up-front cost to build out a dev environment using a framework, it's cheap to keep using it. Another huge factor is that relative to the web experience of, say 15 years ago, there are many incentives to push a lot of work (especially validation of inputs) client-side; few places have truly full-stack developers (or, more often, don't allow the authority for one developer to go hacksaw into the front and backend whenever they feel like it), so simply implementing one new validation rule may be a bunch of back-and-forth tickets if implemented server side or a couple hour's work if done client-side. And client-side work saves the server computation costs (and often bandwidth costs, even when one factors in the up-front cost of loading all that framework boilerplate if the site's used long enough per session).
All of this pushing of complexity to the client does come at a cost of client performance (and sometimes bandwidth, depending on how solid the caching logic is), so (especially at big companies like Facebook and Google) it's a constantly-shifting tradeoff. Google in particular has some incredibly clever partial-rendering logic in-house to allow them to push pieces of a big page on-the-fly to the client, saving bandwidth by rendering a mock button with no behavior attached until the user tries to click on it (and then the behavior script flies in as-needed). Of course, that's a huge amount of complexity that requires tight hand-in-glove coordination between client and server, so the framework that supports it is even more thick and robust, etc.
At the end of the day, "simple web sites" (unless they are truly read-only, in which case just use Hugo and call it a day) are still client-server distributed computing problems with complexity that scales nonlinearly.