I agree. Separation of concerns is a very good design pattern. MVC server frameworks (like Rails and Django) have already separated out the concern of displaying data to the user with their template systems. its a very reasonable next step to just migrate the entire template system off the server and let the client do it.
This has gigantic performance increases for servers under heavy load, and it puts the display logic in a domain that is more naturally suited to dealing with it (JavaScript and the DOM instead of treating HTML as just a string).
The pattern also promotes the use of RESTful APIs for data access from the server, which has the wonderful bonus of allowing you to make your data publicly accessible for free if you want to.
Templates... ok - that's fairly convincing. I'm less convinced about keeping the model and controller client side, because they end up replicating stuff that still has to live on the server anyway, to some degree. That just seems to make things harrier than they were to begin with.
I think if you are trying to replicate the same functions you are right. But if I have, say, a User model then it is merely a conveniently name for two groupings of functions.
My client side user should know nothing about Dbase lookups or persona verification - just as server model should not care about displaying addresses. Overall I think getting the crap out of the server makes it much much easier to reason and architect
