Cloud API's don't exist, but become costlier over time

I had a discussion with George Reese on Cloud and API's, starting with me saying I'd support a maximum of 3 different API versions, and off went the discussion.
His "Max 3 versions? Do you hate your ecosystem?", "What do you mean there's no such thing as a public cloud API?" and "When you cease to support a version of your API, you kill your ecosystem." were puzzling, and he ended with "The bottom line is this: If you decide to change your API, who should bear the costs of that change? You or your ecosystem?"

Let me try to explain here what Cloud is, what API's are, and what cost is

Cloud is a blanket term covering Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). An Application Programming Interface (API) is a term that has come to be somewhat abused over the last years as something Holy-Grail-ish, yet merely implies a method, defined by the application (designers / developers) itself, to interact with the application

In a Service Oriented Architecture (SOA), such an API would be called service. In Integration, it'd simply be called interface. In Cloud, it wouldn't exist: a Cloud API would be just as sensible and meaningful as a Personal Computer API: there is none

An API describes a specific functionality in a specific semantical and syntactical way so it can be used outside its own environment: for instance, you can converse with me about application integration via Twitter. An API connects to the application layer via the infrastructure layer: the application is the first point of contact here

An API is a program, that has been designed and built, and needs to be supported. API's evolve along with the application or system itself, and whenever a specific functionality changes, so (in general) will the API: it will be released as a new version that discloses the added functionality, and will almost always do so via a new syntactical form as well.
"The more the merrier" is not a true statement here: yes the business is pleased to introduce new functionality to its customers and suppliers, but if this happens 10 times a year, the IT-department will be moaning and groaning. And moaning and groaning IT departments mean money, cost.
Design, build and run for a new API release involve cost. Sustaining the old releases also costs, and at some point there will be a break-even point: the profit made from new functionalities will almost equal or even be less than the cost involved with sustaining old functionalities. Then what?

Then, the business-case for adding new functionalities has to be re-evaluated, simple as that. And if you're following your business closely, you'll want to do this before you hit the swamp knee-deep beyond the point-of-no-return

So, you will want to support a few versions of one and the same API, but not too many. After more than a decade of Integration, I've learned that posing no restrictions leads to dozens, if not hundreds, of API-versions over a few years time if you're talking about an enterprise. SaaS will typically outsize an enterprise by a 2-digit factor or more, so guess what? You'll want to restrict the number of versions

Three is a good number in my experience. With a bit of smart design you can even squeeze three functional versions into one and the same technical version so it's fully backwards-compatible, and cost-efficient of course

Cost doesn't exist on a standalone basis. Whenever you talk cost, you must also talk profit: they're Yin and Yang.
Releasing a new API version costs money for the application provider, but it also turns into profit for the business: maybe they can increase their market share this way, retain market share while they were losing a lot, etc: that will be in the business case.
Using a new API release over an existing one by an application subscriber (someone who wants to use the functionality from outside) also costs money, but then again, that design / build / run will not be undertaken if there isn't a solid business case on that side either.
If you're a popular application provider, people might even want to pay more for using the new API release: money travels in mysterious ways

So, where is most of the cost located? In the very back at the application provider, where the old API releases support an ever-shrinking number of application subscribers. You can charge more for their use, but that won't help in or even near the end. At that point, it's becoming an expensive ball-and-chain that you want to get rid off.
For old-fashioned distributed systems (like e.g. Microsoft's operating system), the solution is easy: you just end support and your problem is out of sight, out of heart.
For new and shiny centralised systems (like e.g. SaaS) that is a bit of a problem, as they have to go through you whenever they use their old near-deprecated functionalities. You can increase cost, squeeze bandwidth, limit upload and / or download size, and torment them in dozens of ways - and hope they just go away

Or, you can simply support only a number of versions - let's just say 3 - and prevent the entire problem from becoming one. What would you do?