* Language bindings: The decision to create and maintain an API binding in a particular language is mostly a political decision based on what your API consumers want. It is a trade-off between convenience for the consumer and extra work for the API developers. You will probably develop bindings for popular languages. But what if a language is very popular but also one that developers are unfamiliar with, so it would be a high cost to learn the language and develop the binding? Both the developer and the consumers are invested in the resulting decision, which makes it political.
* Performance characteristics: This can be political as well, because in a sense it's a negotiation between the developer and the consumer. How much extra work should the developer do to save the consumer some time? How much of the computation should be done "behind" the API, and how much should be pushed onto the API consumers?
* Protocols: Each protocol has costs and benefits for the API developers and for the consumers. For example Apple chose to expose their push notification service over TCP, not HTTP. This has costs for the consumers because now they have to use a 3rd party library to handle a new TCP protocol (or implement it themselves). On the other hand, Android's push notification service uses HTTP POST, which is more developer-friendly. I would argue this is a political decision (and a deliberate one on Google's part).
* Latency: Typically reducing latency costs the API maintainers more dollars, but it makes the consumers' applications more performant. This is also, in my eyes, a case of a political negotiation. How fast can we make it so that consumers are satisfied, while spending the least money? Or from the consumer's perspective, how much latency is "acceptable"? This embodies a political trade-off as well.
You could probably make similar arguments for almost every other API characteristic. The simple fact is that almost everything that involves multiple people with selfish interests is at least somewhat political.