Note that there are two major security flaws in Plaid when it comes to authentication:
Since banks don't provide secure mechanisms for third-party authentication and authorization, e.g. OAuth, Plaid receives you credentials in plain text and will then use them to communicate with the bank. So you really have to trust Plaid.
The second weakness is even more dangerous: Apps implementing the Plaid authentication flow will show the Plaid "login page" with bank selection in an overlay on their own sites. Since this is not a redirect again, you don't even see whether your credentials are transferred to Plaid or the third-party app. That is, you have to trust your bank (sure!), Plaid (okay!) and the app using the auth flow (dangerous!).
The lack of secure auth mechanisms is exactly why companies like Plaid (and Yodlee, and Dwolla, and Intuit) exist. Take away that constraint, and this is easy enough to package as a library and not a product.
Many "disruptive" industries like this "API on top of legacy systems" segment are merely arbitrage schemes; they profit from entrenched players' greed and apathy. Luckily, banks are starting to wake up.
As such, it's not really Plaid's responsibility to "fix" this problem, it's the banks'.
Just because this is the reason for Plaid's existence doesn't mean you should make a product where security cannot be guaranteed for the user. Some things just shouldn't be done, because they're not possible yet. Not possible because support from the banks is lacking.
You're asking Plaid to leave $44 million on the table and walk away in the name of best practices. This is noble but unrealistic.
The security flaws boil down to the requirement that the end user must place their trust in Plaid. Plaid considers themselves trustworthy and competent enough to act on the customer's behalf with their credentials. If Plaid were to suffer a breach, their customers would not purchase their services. It is in everyone's best interest to avoid security breaches.
The web product is indeed worrisome, but it's also in Plaid's best interest to avoid dealing with fraudsters.
The unfortunate part here is that the banks have zero liability in the case that their customers lose money due to a breach of their online banking credentials. This could be solved via legislation, and I'm willing to bet that would light a fire under the industry to start embracing options such as OAuth and restricted-access credentials.
I've worked on integrating Plaid into a project recently. Before getting access to the production version (more than 100 users), there's a pretty thorough security questionnaire (hopefully followed by some fact-checking on Plaid's part) for the client.
They are doing their best to weed out bad (or security-ignorant) actors, but there's only so much you can do with banks directly, like you mentioned.
Since banks don't provide secure mechanisms for third-party authentication and authorization, e.g. OAuth, Plaid receives you credentials in plain text and will then use them to communicate with the bank. So you really have to trust Plaid.
The second weakness is even more dangerous: Apps implementing the Plaid authentication flow will show the Plaid "login page" with bank selection in an overlay on their own sites. Since this is not a redirect again, you don't even see whether your credentials are transferred to Plaid or the third-party app. That is, you have to trust your bank (sure!), Plaid (okay!) and the app using the auth flow (dangerous!).
You should fix this!