I'm still not quite there.
>real-time requests
What's this mean? If you're describing the ability to transfer the web site's data whenever a request comes in for that data, that's been the case since day 1. Alternatively, if you're describing the ability to make changes on the fly and re-draw the web site without a full request/response cycle, is it still a static web site?
>process payments
This really doesn't count though, does it? After all, the processing is occurring elsewhere: a third-party payment service or somewhere within the infrastructure behind the web site. It's more-or-less sending a request to some place else to process a transaction.
>manage customer accounts
This is similar to the previous. There's not a whole lot new going on here; you'll have to expand.
>Cheaper – Not making requests to the server on-demand
I don't understand how not making a request is intrinsic to any type of web site.
>Faster – Served from a global CDN close to your users
This just describes the location of the data; nothing to do with the web site.
>Easier – No complicated deployments, better DX
Now this might have some merit to it. Over the course of time, technology evolves and tasks which were more complex 10 years ago may seem trivial today; the technology you're describing could indeed be one of the choices available today.
>How is this reshaping the web? In a way, we've come full circle. What's changing is how we get to a static site. JAMstack unlocks all the benefits of static sites with today's complex data requirements.
Come full circle to what?
We also haven't changed how we get to a static web site; a client calls a server and the server might respond with some data. I would navigate to your website the same exact way I would have 10, 15, ... years ago.