The statement "the web is stateless" is a bit misleading, while I would have found something like "HTTP is stateless" more accurate. As said in the above comment, applications are usually stateful (they internally manage a link between a succession of events --HTTP requests--). HTTP requires the programmers to handle this state (the link between a sequence of HTTP requests) internally (which is done with cookies).
Take SIP for instance, you will see that this protocol explicitely stores state (the notion of "Transaction" and "Session" to which requests and sequences of request belong), which is quite helpful... but can also be done internally on top of HTTP.
Now, regarding continuations, they are simply a way to "slice" a process and to automatically weave and rejoin the slices together, so that the programmer does not have to carry the burden of finding where the program was last interupted. They offer a process-based (or "dynamic"-base perspective) as opposed to a state-based (or "static"-based) perspective, as it is the case with most framework.
So it's rather a matter of perspective, instead of a implementation -- and then I wouldn't say that this perspective is a dead-end, it is just different, and IMHO closer if not more fitted to the domain of communications, from which the Web stems.