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?"
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?"
Client request 2:
Bank reply 2:
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:
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.