I think, todays webapps are closer to real, full-blown desktop applications than they are to the linear, static, book-like presentation-flows of the early web.
That insight has a number of important effects. Application-state and with it the ability to bookmark and history-navigation is one of them.
If you think of the early web as a better book, static “pages” of text and pictures, that you can browse and jump around in to different pages by the use of links, it makes sense to be able to “bookmark” certain pages and also flip back and forth through your history of visited pages.
Now think of a typical desktop-application. Does it make sense there? Can you ‘bookmark’ a certain point in the app’s state, or go back to it? No, it does not make sense. The only part of a desktop app that a ‘state’ can sensitively be applied to is the model. Think about apps that manipulate some kind of data (most do). You have an undo-redo history to quickly take back any modifications to the data that you made.
You might even be able to ‘bookmark’ a certain chain of actions, sometimes called actions or macros. In desktop apps, bookmarks for specific model-states only make sense in a particular context, thus the need to execute the whole macro to get to a specific state of it. Think about it: Does it make sense, even if you could, to jump to one particular point (that is state of the model) in an action without executing all the steps before it? No, mostly it does not.
Now, why would you want to be able to do bookmarking in a web-app, if it does not make sense even in a desktop app? Because it is a remnant of the early days of the web? Because browsers support it, and users simply expect it?
There is the other issue of URLs. Even if you wanted to create a link to specific state in the app, bookmarks only save the URL. How can an application encode a possibly very complicated state in a single URL? Read http://www.subbu.org for a discussion of this.
Where does that leave us? My view is that web-apps should limit navigation-history to changes of the model, similar to undo-redo in desktop apps, and allow bookmark creation only at feasible points in the app when there is still not much state involved – e.g. right before login, the landing-page etc. Most current web-apps already do that: change the URL on creation time by hooking into the event or keeping the path sent to the browser static. GWT lets programmers do that already and also allows to hook into the browser’s history tracking for the same reason.