If I understand your question correctly, the main benefit of doing this is (if it's done well) it decouples your UI from the services. A secondary benefit is potentially simplifying client interactions. API is a term that can be used to describe the service interface as well so I'll refer to the API in your question as a wrapper library.
You mention that it makes it easier to switch to a different interface which is true but I think it's actually the ability to change the services without forcing work on the client team. For example, let's say you have an old SOAP API and you want to move to REST. If your user interface is calling the SOAP services directly, then the client team will need to modify their code in order to do this. If you client only depends on a wrapper library, you can have the service team make do all the work and deliver a wrapper library that is backwards compatible. In the somewhat unusual case that you have more than one set of services or sources, this could be a highly effective way to interact with them using a single UI. An example of this is something like DBeaver which can work with many different database. Internally, I would wager they have a single 'canonical' API that is DB agnostic, at least to some level.
Another reason is that you might have multiple clients. For example, you might have a GUI, a CLI, and server-side background processes that all use the same service layer. Now, when you make a change to the services, the ability to provide backwards compatibility through your wrapper library becomes more valuable, if (and it's a big 'if') all your client applications are able to use it. This tends to not be the case in my experience.
The above applies to 'generic' interfaces. You say these are not which would tend to lead me to Robert's answer.
The other potential benefit is that you might be able to simplify and/or optimize the client interactions. Say you have a REST API where you have to first retrieve a list of resources and then retrieve each of those resources. A client wrapper could accomplish that in a single function and produce a list or stream of deserialized objects/structures. Depending on the skillsets of the client team, this could help them focus on the UI work.
I would expect the wrapper library to be managed by the team building the services. Updating the library should be part of making any change to the services.
Now if this is a purely client-side library managed by the client team, it could be used reduce duplication in the client or simplify the interactions as discussed before. But if this API is an isomorphic pass-though, then it's likely pointless and could just be inertial.