Loosely coupled APIs and services is an old idea, Amazon live by it, even internally. However it is true that most enterprises failed to adopt it. And I agree with the article that companies that write every piece of functionality with API in mind, will have the upper hand in the long run. And those stuck with monolith closed systems will eventually pay a price due to inability to adapt to rapid changes.
If calling it API will convince the decision makers to provide budget for internal APIs even though no customer is paying for it directly, then I don't mind. But this is not a new idea. the problem is how to justify ROI for making your code API friendly (doesn't go without saying by the way, there is a price, of backward compatibility, documentation, decoupling etc). For most CEOs this is a waste of time unless there is a direct revenue path from it (e.g. a customer pays for it). It's hard to justify extra effort on the code to management when all you can say is: it will pay off in the long run (imagine the link to the relevant XKCD here)