A pretty common use-case is going to be creating native mobile apps which work agains the API. Creating a customized mobile experience with WordPress on the server-side is going to be easier than ever. You might be able to think of it as "remote theming".

Another use-case might be server-to-server communications. You could easily create a network of sites, hosted on completely separate servers, which communicate with each other, pass information back and forth, sync with each other in various ways.

Yes, you can do some of that now with the old XML-RPC APIs, but the new APIs will be more comprehensive, and more consistently designed.

I think any fears of this "replacing" regular WP use are unfounded. This is an addition to its existing strengths. There may be specific niche products or services which use this as a basis to "replace" the existing front-end and/or back-end, but I don't see that weakening WordPress as a whole in any way.

The main thing that this is replacing is the old XML-RPC interface. As someone who put a lot of work into that area in the early days, I'd say that this is a good thing. The XML-RPC APIs were a mess -- not WP's fault (or mine), it was that way already. It was three layers, haphazardly built one atop the other, starting with the original (and very limited) Blogger API, then extended with the metaWeblog API (an attempt to create a better, more universal standard), and then further extended by the Movable Type API (which filled a few more gaps missed by metaWeblog). Furthermore, the XML-RPC protocol itself was a bit ugly. But at the time, JavaScript was still a bit of a mess, JSON was barely a thing yet (hardly anybody had heard of it), and while there were various things happening with remote requests in the browser, the term AJAX was still on the horizon.