Solve a problem someone has first. Rarely will that solution be an API. Advice is never universally right or universally wrong, but the advice in this post is almost universally wrong.
API first is actually right in my opinion. Software is very multi-platform now : if you build the API first and then build the clients on top of that, you can make the clients completely decoupled from the server, allowing you to quickly switch platforms.
Technically, API first is a good thing. I don't know about from a business sense.
From a business sense you want to ship a minimum viable product as soon as possible. There may be teams that could do this most efficiently via the architecture you describe. I think most will work faster with one less tier.
Shipping an MVP with the most basic UI that gets JSON data from the server is fast and usable.
It was difficult to do this in the past, because browsers could not support the data that returned from the server without a lot of work. Today, JQuery that can present the data with minimum effort.
In some part I agree with you., but that's now. In the near future more and more services and apps will have an API as a primary way to be accessed by third party developers.
Don't know if that will be your need since all depend from the service itself if it is useful or not. But we have to bear in mind that Twitter has 75% of its traffic coming from its APIs, while eBay has 8 billion of worth items pushed through the marketplace via APIs. That's the future, especially when the internet of things will come, at that point your toaster will have an API as well.
Twitter and eBay both had significant web presence and community before their APIs took off. So did Facebook. Only once you have something worth getting at will people want to integrate with you.
To be fair, a lot of Twitter's success was due to their API, but without a decent minimal web presence, nobody would have signed up. Remember, everybody's first Twitter client was the web. If that sucked, or didn't exist, nobody would have bothered to pick up an API-based client.
However, Twitter later found that there were many problems with their system, and had to completely redo everything, to the point that '#newtwitter' now is just an interface that sits on top of their API.
So maybe it would have actually been cheaper in the long run to have built a perfect API first, rather than a web service followed by an API.
