As an example, I recently had to pay for parking with a website because the card reader on the machine was busted. So I scanned the QR code and loaded up the site, had to fiddle to enable some of the scripts, and make my payment. After I was done, I saw it had used over 25 MB--4% of my data for the month--to collect roughly 30 bytes of information from me, assuming a naive encoding (16 digit CC, 3 digit CV2, 8 digit license plate #, 2 digit state). Maybe it also needed the billing address, so another 30 bytes or whatever. Point is the TLS handshake should've been 95% of the traffic.
If anything, I almost left to go look elsewhere because it was too much of a pain to get it to work on my phone and I didn't want to use up all of my data fiddling with it. No one is demanding a JS heavy site here. Customers are not demanding anything. It's a near certainty that no one has ever provided feedback to the parking lot owner about their payment form. I did actually leave digikey's store because I literally could not figure out how to get their payment form to work without blanket enabling all scripts (and they have a ton of third-party tracking scripts).
Sites that are for services that actually matter (e.g. banks, governments, utilities) also don't need to be flashy. You don't need to sell me on filing for my paternity leave or filing taxes or making a bank transfer or paying a bill. Just present the form. The absolute ideal website in such cases is a transcription of the paper form it replaces with a tiny bit of javascript to check constraints/field validation. The free tax filing website for the US is a decent inspiration for this: from a UX perspective it's just electronic versions of the paper forms with some ability to auto-calculate some fields.