In fairness, it's a great example. Moving money between accounts requires updating the state of at least two records. Moreover, nearly everyone working with databases has one or at least understands how a bank account should work. And as far as relevant examples go, I can't think of anything else where the correctness of the operation is quite as critical.
It's a bad example because bank accounts don't work like this. Accounting etc use an append-only ledger.
There is no one true way that bank accounts work. I work for a big bank and I've come to accept that there are valid cases for UPDATING and even DELETING transactions in your Core Banking system. It is true that your general ledger is append-only, but that doesn't apply to what happens before you close your books.
Yeah, there's a reason and that's the reason.
I just wish it were applicable to something else.
It's a deceptive example because banks are distributed systems (in that they interoperate with other banks/financial systems, and often have distributed internal database systems across multiple products too). Regular db transactions are insufficient for ensuring consistency across a distributed system, primarily because one of the systems may fail to commit their transaction after the other has succeeded. Even if there is only a single database, protecting data against concurrency issues is still non-trivial even with transactions.
I mean, if your argument is that banks don't use the primitives of a standard RDBMS because their needs aren't serviced by a standard RDBMS, of course it's a bad example because you're talking about how to do something in SQL which isn't done in SQL. But that's not a "bank accounts" problem, that's a "how banks with a non trivial number of systems work" problem. If you were implementing a system for managing bank accounts in a single RDBMS, regular transactions would work.
The problem is that the industry standard of banking is eventually consistent. Whilst having atomic transactions is necessary, it's not sufficient: Using banks as a teaching metaphor for RDBMS systems is like using animals as a teaching metaphor for polymorphism. From a naive point of view it works, but it does more harm than good because students walk away thinking that they have a solution to a problem that isn't actually sufficient for it.