Actually it's a cost and simplicity issue. You have to pay each merchant for the transaction type, so that adds to your costs. You pay commission per sale which is standard, but most need you to pay a fee as well (especially if sales are below a certain amount) which many retailers would rather not have to do.
More so, if you got to many e-tailers (take amazon as an example) although they take several payment types you only see one system. Having looked at such implementations for some clients, you tend to find that most need you to use their system or at least their system wrapped in your page layout rather than you having control over each. Thus adding multiple payment systems, many of which may overlap, would simply confuse and irritate customers.
If you went to an online retailer and wanted to pay by card, if you were offered 3 ways to pay by visa you'd be a bit miffed as to why they couldn't just sort themselves out. I accept your alternative would allow for the retailer to auto-switch to another merchant but that comes back to cost, maintaining the other pages that rarely get used, and the confusion for regular customers depending on the sort of company you are.
As a professional merchant providing a service, HSBC have a duty to inform their customers of any issues, especially at peak sales times such as weekends and evenings, and this isn't just an exclusive communication to their large branded clients. I certainly would think twice before suggesting a client use them for their systems in future, such events can only be bad for business.
You'll also find that where a company looks like they're processing their own card details, 60% of the time they're simply connecting to an external api for a more technical merchant, so still aren't processing their own payments.