Sorry, I misread your paragraph about storing stuff in the RDBMS.
The big win, as you put in, in the continuation paradigm is that rather than write a scattered set of scripts that respond to an ansynchronous batch of HTML requests, explicitly passing information via hidden form variables or (in OpenACS) session variables stored in cache backed by the RDBMS, you write your code as though you're communicating using synchronous I/O.
The framework handles the problem of issuing the asynchronous I/O requests and the saving of state information across the stateless stream of HTML request.
The size of this "big win" probably is directly proportional to your perception of just how difficult it is to write web UIs the traditional way. Most web UIs for practical sites are quite simple, so the win for desktop GUI applications (which also generally run in a more complex application environment with a rich set of events to respond to and trigger) might be much, much larger ...
