Betrayed by LinkedIn

It also sounds like a change LinkedIn were considering for a while that might have been avoided by sending an email stating "We're planning on building an app dependent upon the the X API call to do Y. Could you please let us know of any changes planned to this feature." If my business model was that tightly coupled to LinkedIn's API and nobody got back to me I'd take that as a warning sign.

And it doesn't necessarily have to be a "bad will" from the power supplier.

I know a store who went down because they were relying on a unique supplier and, at one point, the supplier experienced an issue at their factory, outside of their control (a flood).

The supplier was big and strong enough to deal with the momentarily slowdown (it lasted months) but the store I knew simply couldn't handle their customers' orders and couldn't accept new customers. It quickly degenerated: unable to pay the salaries, then unable to pay the bills, the tax, etc.

And the store, after years of "faithful" services, went bankrupt after a few weeks/months. The sad thing is you could see them trying desperately to stay alive and they were nice people.

So it's as you said: be careful to not depend on a power supplier because several things may go wrong.

Short Answer: AWS provides a agnostic service focused on utilization with no specific purposes in mind, hence a metered system makes perfect sense. Twitter only exists with user driven content and needs a constant pipeline of the stuff to survive, and because the web application is free in order to eliminate barrier to entry, implementing a metered system for developers would remove incentives to build new applications because they're having to pay to compete with something people can get for free.

Long Answer: You can easily explain why a metered system works for a company like AWS because you're renting a agnostic hardware platform you can do anything on from building the next Twitter to serving cat videos to grandmom's mobile device. In this case, they can consider all usage and bits equal and charge accordingly. It gets murkier when you look at companies like Twitter or Facebook that are trying to be content companies and global platforms at the same time. These kinds of companies make money by getting users to post content to their service, letting them sell targeted ads, compiling user profiles they can sell / reuse, and by selling content to third-parties who can analyze (i.e. Salesforce purchasing access to the entire Twitter firehose). Subsequently, most consumer oriented development on these platforms focuses on the posting and accessing of content and, in many cases, consists of standalone applications ranging from open source to paid for with a couple SaSS platforms thrown in for good measure. Monetizing this ecosystem poses two separate challenges. First, the external applications hide user data from the content company. Coming through an application, the app can send the bare minimum necessary for an HTTPS connection to the API and the company won't know if the user's on a mobile device or computer, what O/S and version they're running, the actual time of the interaction (for instance, sending a delayed tweet) and a whole host of other user metrics. This decrease in information hurts Twitter's ability to build user profiles and vector the user to things they might pay for. By tightening their grip on the third-party ecosystem, Twitter ensures the flow of information necessary to keep building these profiles.

Secondly, creating a metered usage system for a content company would flip the revenue system, developers would be subsidizing users using the content platform unless they send users a monthly bill for their usage of the app. This would completely destroy any third-party ecosystem since the web app is free. Why pay a monthly bill to use a otherwise free service? Sure, you might see some adoption, but I would argue it'd be microscopic compared to an ecosystem built on a free API.