Give me client side data binding (2 way!) any day of the week vs sending the partial back from the server side. You invariably end up with a bunch of shitty glue code that's dealing with the actions AND the display.
Using a framework (Angular, Ember, KO, Backbone) all allow you to separate this spaghetti nightmare into manageable chunks.
For the people who do, pushing data & logic into the client is fun, working with js, working on the actual "single-page app" & updating logic/css/html simultaneously.
For people who are more into static typing / web back-end, & don't particularly like the process of writing js, there is a nice movement toward dynamic pages where the updates are concocted through data-binding & behind-the-scenes ajax (generated by the component libs...). For a lot of enterprise Java devs, the dream of having an ultimate single source of domain logic in the Java layer somewhere lends itself well to this solution. You code typical OO paradigm and just try to integrate those models naturally into the front-end binding.
For the project I'm working on, pages are generally comprised of large blocks of content, and to the extent that there is SPA going on, it's mostly swapping these blocks. I can definitely see the advantage of client-side rendering when model data tends to be spread out across the whole page. But there's no reason one can't have their cake and eat it too.
Two output formats is a reasonable solution, but one that you don't have to maintain if you go with a framework (such as Angular) that can render JSON back into HTML. It really boils down to whether you want to support a more complicated server or a more complicated client (or drop support for any clients that aren't yours).
I did a Rails app serving JSON exactly one year ago, to a small Angular front end. It's was a little disheartening to see an empty page loading and then making JSON calls and thinking that by then a server rendered page would have been already fully loaded. That's why I said that it's all or nothing: either a single page app or many html pages. A few single app pages don't do well, unless they are preloaded with server rendered content.