You can definately go too far and implement too much on the client side, and this is generally a bad approach.
It's like with anything else. You need to figure out the balance between what you process on the server and what you process on the client.
There's plenty of reasons you might want to avoid this in some cases. For example, you might want your forms to be validated without waiting for the user to push submit. You might have rich content in some markup language (like markdown) and you want the user to have a live preview on the same page as they are editing. Or you might have an app with real time data that changes frequently and you don't want the user to sit there pushing refresh constantly.
You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.
It's true that it doesn't give you any magical power that you didn't have before and you can do everything it can do with vanilla javascript or any of the other frameworks. However that's a bit like saying you don't see the point of rails because you can just use vanilla PHP for everything.
The simplest way to use AJAX with a server-side MVC is by fetching blocks of pre-rendered HTML. This is commonly known as AHAH. It's dead-simple to do, powerful and trivial to use via progressive enhancement. That is what you should treat as the server-side alternative to client-side MVC.
Instead of writing your own code to handle AJAX on top of jQuery, you write code that handles the real logic and let the framework handle the DOM manipulation. In that way, it's easier to test, easier to debug, easier to provide superior experiences.
Right now, writing AJAX in the browser is equivalent of the JSPs of yesteryear. Remember all that horrific logic that used to creep into your JSPs? That's what jQuery looks like, and this new crop of frameworks is getting us to JSTL or facelets at the minimum.
Which is non-semantic, so it cannot be progressively enhanced, does not benefit from browser updates and is pretty much not crawlable by anyone except Google.
How does Ember.js in the clients browser scale when you have a a lot of data that needs marshaling / unmarshaling or generally processing and moving around? Surely it's more performant to do this on the JVM on the server rather than relying on the clients computing power (or lack of). Ideally you wouldn't do a lot of data processing in the MVC part of an app anyway but it seems like you're telling me the whole web app needs to be client side?