API providers are typically businesses or other actors whose interest is to lock the API clients nto their service. What would they gain by making their API interoperable with their competitors?
That is only viable for newcomers into the type of service and only works if they clone the API of an established player, not improve on it and standardize it.
They don't have to make it interoperable per se. It'd be enough to use some terms from a shared vocabulary (user, account, address) and then have some business-specific terms.
This way the business can use an existing library that knows how to handle user profiles. It's not that the full client has to be generic, a UI component that knows how to present a portion of a dictionary is enough.
I guess the availability (technical possibility of building) of interoperable API does not mean that it will be used in every case. It would be used in cases where there is an economical benefit and vice versa.
Reduced differentiation between underlying services drives them from product world into commodity world. Lower margins and stronger competition at that level certainly benefit the big players. Services in question, maybe not so much.
I think most developers who has had the displeasure of doing integrations with third parties want to make that process as smooth as possible for whomever is to integrate with their system.
Because it also makes it easier to use those API's, and for people to adopt theirs.
So you will find the better services adopting this first, because they can compete on having a better service.