Wordpress - REST API purpose?
At its current state, it is a badly engineered feature that do not have any real advantage for a competent developer.
The basic idea, as it stands at the time this answer is written, is to expose WordPress core functionality as JSON REST API. This will enable decoupling of the WordPress "business" logic from the UI and enable creating different full or partial UIs to manage and extract information from wordpress. This by itself is not a revolution, but an evolution. just a replacement of the XML-RPC API which by itself kinda streamlines the HTTP based for submission API.
As with any evolution, at each step you might ask yourself, what advantage do you get from the former state, and the answer is probably "not much", but hopefully the steps do accumulate to a big difference.
So why the negative preface to this answer? Because my experience as software developer is that it is rarely possible to design a generic API that is actually useful without having concrete use cases to answer to. A concrete use case here can be replacing the XML-RPC API for automated wordpress management, but any front end related has to be site specific and since there is a huge performance penalty for every request sent from the client to the server you can not just aggregate use of different API to get the result you want in a way in which the users will remain happy. This means that for front end, for non trivial usage, there will still be very little difference in development effort between using the AJAX route and the REST-API route.
The two overarching advantages are:
- You can (eventually) do all admin tasks without the admin interface.
- You can get all data for display and eliminate the front end (and writing PHP) completely.
Regarding your example specifically-
Replace steps 3 & 4 with the REST API, and replace steps 1, 2, and 5 with Backbone.js. BOOM, dynamic web application. Or maybe you're more comfortable doing the complex routing necessary for your site with Python instead.
Well, a few things actually.
It lets you run specific functions as needed, rather than requiring all of the computation of an entire page load. So, you could update the comments periodically with fairly low overhead without needing a page refresh by just calling that API endpoint and updating the data on your page. This concept will eventually be extrapolated into SPAs (single page applications) which load the "client" site quickly once, and emulates all page "changes" without needing to re-pull the page's HTML each time. This is already very popular with the advent of frameworks such as Angular, Ember, and React. Sites may respond with blazing speed, while both offloading some computational power to the end-user (render cycle, non-business logic) and reducing the overall number of calls to the server significantly (only pull the data that you need, rather than reloading everything each time).
It separates the business logic and the renderer. Yes, you can use the API with another PHP site spitting out the results, or handle it with Javascript like you mentioned, but you can also consume it with a native mobile application, desktop application, etc. Not only that, but you could have one of each all talking to the same API, which consistently performs the same business logic, which in turn creates consistency and reliability across the various clients consuming the API.
APIs are good because they separate the concerns of logic and display.