I suspect that support cost also played into the decision.
Consider requiring payment: It covers your support costs, and provides some ties to a real-world identity as well as rate limiting/imposing a real cost on attackers.
For credit cards, AFAIK you can set which security level to apply (i.e. whether you'd rather have a higher fraud risk or more shopping cart abandonement because the customer didn't have/want to deal with whatever auth the bank requires at the highest security level). I imagine cranking this to the max would reduce the risk of stolen cards significantly.
I'd imagine requiring
- identity verification (even if you can't link it to the account, it will deter attackers) through a third party provider
- payment (both to cover the cost and as a second form of verification/audit trail generation)
- inactivity of the account
- contacting and warning the user for a week
- requiring the user to confirm a confirmation link at the beginning and end (i.e. an attacker would need control of the user's e-mail)
would strike a good balance. If you don't want human judgement in the loop on your side, it can also be completely automated if the ID check is done by a third party.
If there is no way to recover, it creates a perverse incentive to not use 2FA in the first place.