I recently read Feilding's dissertation of Representative State Transfer (REST). This was primarily motivated by the HTMX guy's essay. I really didn't know anything about REST before reading this dissertation, and perhaps that was for the best.
the web itself is now RESTful. This was due to the hard work of feilding and his colleagues, The primary underlying protocol of the web: URI, HTTP and HTML are all RESTful. The farce technique of JS first applications go against this grain, but that is beside the point. Any good technique/paradigm/language can be abused to uselessness.
The main point of REST was Statelessness, Layered Caching and abstraction of resource from it's identifiers. (feilding later says how hypertext is an essential design, but this was mostly glossed over in the dissertation itself. Since there was only hypertext on the web, there was no need to emphasize that. However, the situation has now changed.) Combining these meant a huge deal of flexibility in the meaning of a URI.
Fielding defines an architecture as an added set of constraints on top of an empty set. This definition is really neat, since what we consider flexibility is also a constraint. Consider the class example of cat | wc . We consider it a flexibility that cat's output can be fed to wc's input, and it's output in turn can be chained into something else's input. However, viewed another way, this means wc should take it's input primarily from it's stdin, and the useful information must be spit out on stdout. Since the output is generally un-structured and prone to be usable by other programs down the pipe, this means any change in output format is also not desired. (Many "helpful/user-friendly" cli applications don't follow this pattern). Thus, using unix pipes means constraining programs in how it does it's input/output.
This constraint means that a program should not try to do many tasks, as that makes it *less* flexible when used with other programs. This is a constraint, but one which we accept and hail as a good philosophy. (The unix philosophy, if it should be called that, is much more deeper than a tagline to repeat). This constraint is accepted to make a program more general *within* the unix framework. Constraints similar to this define what we expect out of unix. Thus might be the reason on why "newer innovations" are hated by some --- they do not fit the model of the OS (c.f. systemd, dbus).
Similarly, the constraint of the web (stateless, cacheable, abstract (and hypertext)) should be celebrated; whenever we design a web application, those should be kept first in mind. To keep state, the whole necessary state should be transferred for each request. Following those means an application well suited to the web's fundamental architecture. It should be easier to build, use and extend.