The problem isn't banks not having APIs, the problem is not having standard APIs for accessing them. The situation wouldn't be any better if every bank had its own proprietary API, hence why Plaid exists.
The situation would be better than it is now, even with every bank implementing their own proprietary API. As it is now, the APIs may or may not exist - and a lot of times the fall-back for these services is web-scraping, using the same full access credentials the user has to use to log in otherwise. It's a security nightmare and it's fragile.
At least if the bank implements some sort of API that means some thought was probably given toward using tokens instead username/password, and some thought was given toward scoping the APIs - at least into read-only and read-write capable access.
Although if you read between the lines in some of the service descriptions and backend documentation, a lot of what Plaid (and Yodlee, and others) do is now a mix of scraping and private APIs the banks provide, but those APIs are only available to commercial entities they've signed a relationship with.
Obviously the ideal is public standardized APIs all banks provide with established security-focused practices and read-only limited data access as an option. But proprietary per-bank APIs available to the general public would be a good step forward.
> The situation would be better than it is now, even with every bank implementing their own proprietary API.
Well, I think that would barely change everything on the consumer side. Nobody is going to go through and integrate with the hundreds of credit unions and local banks just for their app - if anything it only encourages a few extra companies enter the battle with Plaid.
