This is a terrible idea which encourages people to use weak security: it's effectively telling people that if they enable MFA, GitLab will ensure that they suffer irrecoverable damages — but if they don't enable MFA, everything is recoverable. That is the opposite of what we want from a security perspective and it risks causing users to be less secure everywhere else because having seen that message will make them question whether they'll regret enabling MFA even on sites which have good security policies.

GitLab should respect the trust that users place in it and account account for the kind of life events which happen to people every day: houses get flooded or burned, safes are burgled, people have to leave abusive situations in a hurry and may be escaping household members who actively try to sabotage them, people die without having made perfect handover plans (especially relevant this year), etc. Of particular interest, consider why the browser manufacturers reversed course on HTTPS key pinning after seeing attackers successfully use it to prevent legitimate users from regaining control — if implemented, this would make it extremely risky to use GitLab because everyone would be one compromise away from an attacker having permanent control of your account — and that would make GitLab look extremely bad for having put themselves in the position of supporting the attacker _unless_ you pay GitLab money (I am certain this is not the _intention_ but it is definitely how it would look to say that FOSS developers are second-class).

There are a number of fallback techniques which can make most of those situations recoverable, and it's okay if they're slow or inconvenient — nobody complains that their airbags are messy. Some ideas:

1. Have a process where someone can use a trusted third-party to verify identity: for example, register identifiers (drivers license, passport, etc.) and have a form which can be notarized after checking ID and mailed in. It's slow but that works even in the “I lost everything I wasn't wearing” scenario — and if you did just lose your house to a natural disaster or flee an abusive ex, you probably have bigger concerns than getting control of your GitLab identity back in less than a week.

2. Configure next-of-kin / trusted friends who can approve a reset request, perhaps requiring more than one.

3. Allow the user to configure some number of IdPs to approve an unlock, increasing the level of compromise that an attacker would need to hit before getting the ability to perform a reset. There are drawbacks to this approach but most people do not have threat models which are meaningfully resistant against someone who can compromise multiple of {Apple, Google, Facebook, Microsoft, login.gov, etc.} and could be pretty effective combined with a time-delay (e.g. send notifications for n days before actually resetting MFA.