The way that this post describes porting and existing interface from server-side/ajax rendering to client-side rendering is particularly interesting -- I imagine that there aren't many apps that have made that jump after first being built around server-side templates.
The speed benefits that Diaspora is seeing from distributing their HTML rendering is probably only the first step. There are so many more interesting interactions you can accomplish once your data is being modeled in the browser.
Personally, I've rewritten a bunch of code at work to go from server-side rendered templates (in Jinja) to client-side rendered templates (using a Jinja-to-JavaScript compiler I wrote, https://bitbucket.org/djc/jasinja). Add some WebSockets magic and we now have a very fluid real-time application page.
The model is obviously very powerful. The one problem I have with it is JavaScript-the-language. Using it makes me love Python so much... I know it's not that bad and there are good parts, but it's still nowhere near Python.
IIRC, foursquare.com's client side was recently rebuilt in Backbone and now they retrieve all data using their API. It's an interesting trend that I think more and more large websites will follow.
It's a very pure model which is extremely appealing from a last-mile-developer standpoint. Actually building everything that you need to get there is the challenge, but it's a very worthy goal.
Live re-rendering of data -- imagine if the (now) "24 minutes ago" timestamp next to your handle was always accurate, instead of just reflecting when I loaded the page.
Easier implementation of otherwise difficult features. Doing a client-side autocomplete of people's names is trivial when you already have all of the other accounts in your organization modeled in JavaScript ... but not as fun when you have to ajax for server-rendered HTML for it.
Live updates of pushed data. When another reader +1's a post that you're currently looking at, if the server pushes that data to you, and you have a model for that post -- it's easy to increment the counter. If the server has to push the re-rendered HTML for the entire post, it's much more difficult.
This can be done without the radical switch to modeling everything client-side. I mainly do java web apps with JSP's (which everyone seems to think is stodgy and past its prime) but its rather simple to do something like what you're describing with keeping things up-to-date. I simply have broken my project down into "widgets" that self-load so a page actually is made up of many widgets that use javascript to call various server-side controllers, you can then set them to do whatever you want (such as refresh every 30 seconds) and it doesn't require some massive client-side data model.
I agree, there are cases where you would want a more robust client side data model, but, IMO people are a bit too quick to jump to using this and it can make more work in the end and make a project more costly to maintain. I think the cases where it is useful are mainly for highly interactive sites like those that would have previously done in flash, with animations (such as games, etc), for just regular CRUD webapps I feel its a bit of overkill
Since Diaspora is based on federation, you might even be able to do some neat tricks having your browser bypass your current servers and talk directly to other Diaspora servers.
There are probably tons of security issues, but for some read-only cases it might be useful.
Ok, maybe not tons of security issues, but maybe some pitfalls.
My imagined use-case is where your friend on a different server posts an event, it gets put into your feed, and when you view your feed you're able to see an updated list of people attending by directly querying the friend's server. Would be pretty slick.
The speed benefits that Diaspora is seeing from distributing their HTML rendering is probably only the first step. There are so many more interesting interactions you can accomplish once your data is being modeled in the browser.