I don't disagree at all, but scaling a dynamic API is still harder than scaling static resources. Saying "we're doing everything through an API" is one solution to the problem of scaling the dynamic portions of the application, which I alluded to.
Something of an aside: You really don't need localStorage to do this. You can still use cookies, you just can't use HttpOnly cookies, and in fact that's what the localStorage polyfills I've used fall back to. The trade-off (drat! there's always one of those) of both localStorage and non-HttpOnly cookies is that it once again becomes easy to steal user access credentials outright if you can manage an XSS attack, which is what HttpOnly cookies helped prevent in theory. On the other hand, in practice XSS attacks can still usually steal an account even with HttpOnly cookies (for instance, by sending a request to change a user's password, which dutifully sends along the valid cookie anyway) or do other nefarious things, so you just can't let XSS happen either way.
Another question is: Is the user experience of applications built this way as good? It definitely can be once everything is loaded and churning along, but the initial load can be quite slow and choppy as data comes back piecemeal. Server-rendering the initial page and doing updates through an API is, I believe, the way forward, but it's still tricky and inconvenient to do. And then you once again need to scale the rendering of full pages server-side!
tl;dr; Yes, that's a good approach, but not a panacea.