It's fun to see predictions in the REST paper (from 13+ years ago) that turned out to be spot on. Here's one about cookies:

6.3.4.2 Cookies

An example of where an inappropriate extension has been made to the protocol to support features that contradict the desired properties of the generic interface is the introduction of site-wide state information in the form of HTTP cookies [73]. Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application.
...
The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser.
...
As a result, cookie-based applications on the Web will never be reliable.
...
A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id.

This problem led to developers putting state into the HTML fragment back in 2005 ("AJAX" – haha). Now we have the History API and pushState to do this. The style of using cookies Roy's talking about is rare now, though you do see it with "message flashing" in web frameworks (e.g., "Draft saved"). Cookies now act mostly as glorified Authorization headers.

More in this series:
The threat model of the Internet has changed Let's remove verbs from HTTP 2.0