You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert.

They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary.

This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted.

tl;dr

2fa:

  Client request 1: "Gimme $5."
  Bank reply 1:     "Who are you?"
  <man-in-the-middle starts listening>
  Client request 2: "StrawberryNewtonManicDresser"
  Bank reply 2:     "Okay, you can now use session ID 1234 to request more money."
  
  MITM request 1:   "Gimme $100000."
  Bank reply 1:     "Who are you?"
  MITM request 2:   "Session id 1234."
  Bank reply 2:     "Okay, here's your money."

client certs:

  Client request 1: "Gimme $5."
  Bank reply 1:     "Who are you?"
  <man-in-the-middle starts listening>
  Client request 2: <'Gimme my money.' ^ PRIVATE_KEY>
  Bank reply 2:     <verifies CR2 against stored client cert>
  Bank reply 2:     "Okay, you can now use session ID 1234, starting at iteration 2, to request more money."
  
  MITM request 1:   "Gimme $100000."
  Bank reply 1:     "Who are you?"
  MITM request 2:   "Session id 1234, iteration 2."
  Bank reply 2:     <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key>
  Bank reply 2:     "You're a faker, get lost."

....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's)

It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.

That seems right to me. It's the same approach as SSH key-based auth in a nutshell

2-factor authentication does not protect against that.

The victim does not know they are being MITMd and enters the 2FA code.

The 2FA device from my bank (https://nl.wikipedia.org/wiki/Rabo_Scanner) shows what permission is asked: account login, signing a transaction for amount x, etc.. You might MITM it, but it would be hard to profit, because the only thing feasible seems to deflect some transaction to another account, and it would only work once and raise suspicion quickly thereafter.

The bank could encode the permission (amount, beneficiary, read access, etc with an expiration date) given into an OAuth bearer token, and the app can use the token to do exactly the things that the user consented to.

I'm amazed (in a good way) that European banks have such advanced security and that the general public goes along with it.

If they tried this at a Canadian bank, every non-technical person would immediately switch to a competitor and they'd lose more money than they'd save via fraud prevention.