There is a fourth approach: store the view state in hidden, compressed HTML form fields to be re-loaded into RAM on the next pass. The problem with this approach is that we cannot easily "interrupt" one form or screen with another, and then come back. Therefore, I will not discuss it any further.
Too bad you dismiss this approach because up until this point you were describing the ASP.NET model almost exactly. Yes I realize your objections to having to pass viewstate back and forth, but the meat of your article was how to make the best of the web situation.
If you are worried about interrupting a form, you could open the new form in a separate window (like most traditional VB apps would), then use client side scripting to trigger a refresh in the original form if needed. Some people seem to also be storing the (hidden form field) viewstate in a (server side) session variable for later use. I suppose you could store it in a table too :)
PS. Have you ever looked at XUL from the Mozilla project? Not what you looking for either (It also uses JS+DOM, but at a higher level of GUI abstraction), but it could be a platform on which to build your ideas. You could make your own SCGUIzed Mozilla based browser.