This is all well and good until you want to handle error responses on the client. Let's say your user is on spotty wifi and they hit the submit button for your form. Guess what happens if that AJAX request fails? Probably a whole lot of nothing, unless you've got some templates client-side to show an error message. At that point, if you're making your error messages fit into each of your UIs, you'd might as well just be using client-side templates anyway and SJR is moot.
On top of that, you can't update the UI in a meaningful way until you get a response from the server.
That's also not even touching any security considerations that you need to make to use this technique: you can't implement a CSP, you've got to make damn sure you're properly escaping every piece of data [in a special way] that comes through, and you've got to make sure the response that you're sending can't be used in a script tag (i.e.: you need to add an intentional syntax error that you strip off) or an attacker could simply put a script tag on his own site pointing at a URL on your site that returns sensitive information.
I worked with someone who helped develop AJAX interfaces before it even had the name, back when XMLHTTPRequest was brand-new, and they built a product similar to this in philosophy -- must have been around 2000.
I worked with a similar model as well on a couple apps, until finally migrating entirely to client-side rendering, and I would never go back. The complexity of server-side code having to write out client-side to update things just defeats you after a while, it's hard to keep a separation of concerns, and things start to turn into spaghetti despite your best intentions. Refactoring becomes increasingly difficult.
But most of all, it's just like you say -- you can't do error handling, or change the interface before you receive a response from the server, or deal with simultaneous requests, or probably 20 other things.
I'm honestly really surprised to see someone recommending this today. Dealing with all these huge numbers of stand-alone snippets which update certain parts of pages in certain conditions, is just an organizational nightmare.
Actually, if you take this approach but with a twist, it's quite possible:
As was shown with Google+ widgets for performance optimization, I.G.'s talks on High Performance Websites and chatter from Polymer-using folks, deliver your first page, your template, using HTML. Pre-render things, but then make it interactive on-focus (if widget), or load your JS and continue loading data (mobile) or take your HTML and use it as starting point for a really nice template and loading framework for widgets (Polymer).
The point then is that JSON is rather useless. It's not optimized binary for machine consumption, neither is it display-optimized DOM, in which styles and content can mix and interact.
Oh and failure states are entirely possible to show. If you want a dumb failure state, code that for use when you introduce the loading spinner as a timeout helper. For more advanced failures, write the logic client-side as you would normally, then deliver and modify the HTML again as you would normally.
No one says that because your primary communication mechanism for server updates is HTML that you can't in turn use JS on the HTML to provide updates between updates, as it were.
I think the reason they do this mostly boils down to wanting to write ruby. If there was a native ruby engine in the browser, i'm pretty sure they would do everything they could client-side.
I think more so than the error case (which is hopefully rare), you lose any possibility of optimistic rendering, where the user sees an immediate response (i.e. the message is added to the UI) while the server updates in the background.
The way this is set up, you must wait for an HTTP request to complete before any UI updates. I don't care how much caching you do, that will always be slower than immediate client-side update.
I really think the best way is to have both - send HTML to the client on page load, and get JSON for every subsequent request.
On top of that, you can't update the UI in a meaningful way until you get a response from the server.
That's also not even touching any security considerations that you need to make to use this technique: you can't implement a CSP, you've got to make damn sure you're properly escaping every piece of data [in a special way] that comes through, and you've got to make sure the response that you're sending can't be used in a script tag (i.e.: you need to add an intentional syntax error that you strip off) or an attacker could simply put a script tag on his own site pointing at a URL on your site that returns sensitive information.
TL;DR: Badasses only.