During my time at Xero we pushed back quite hard against partners (not individual customers/users) using aggregators / api routing layers for a few reasons. The biggest issue was quality of integration/product. When a partner wanted to use an aggregator, that became the limiting factor for their integration, ie: I'm going to build this integration once for Xero/Quickbooks/MYOB/others using AggregatorX so it's only going to support features which exist within AggregatorX, which will limit the integration to features which every product has, and which operate in a similar enough way that they can be supported by AggregatorX.

Now, that might be fine for an end customer, which is just trying to create an invoice and get a payment on it, and may switch accounting systems in the future. (this again depends on use case. I would argue that in most cases if you want to get the most out of Xero + Internal Application, you're bottleneck will become what the aggregator enables)

But if you're using an aggregator style product to integrate, say Shopify & Accounting (Xero,QB,etc), it's ultimately going to piss everyone off, except maybe the product manager who can tick off Xero,QB,MYOB,Freshbooks,etc in one sprint.

The business team who pushed this integration to be built will be disappointed because there is no differentiation in the integration to each product.

The dev teams are disappointed because the specific product features they built that they believe (rightly or wrongly) are better than the competitor, are glossed over because they can't be easily aggregated into a generic workflow.

And end users / customers are disappointed because the features they like about Xero/Quickbooks don't seem to work when integrated with Shopify (example only).

There may be a place for aggregators, but they need to align with the interests of the parties behind the integration. Making the integration easy for the dev team is great, but not at the expense of the purpose of the integration for the customer, the product and the business.