>Plus you've got the extra layer of an API to maintain too
On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.
Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.
This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way.
The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...
On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.