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.
There are challenges of this approach.
PS: Lots of downvote when it comes to Java and GWT eh...
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.
... and those are just the tip of the iceberg.
There are probably tons of security issues, but for some read-only cases it might be useful.
I don't think there necessarily are, since CORS allows cross-domain communication to be done in a safe, controlled way.
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.