I recently switched distros on my work laptop and went on holiday. I didn't take the backup drive from the old install with me. I use KeePass. My company uses LastPass.
I had to log-in to LastPass, so grabbed my username and password from KeePass, and tried to log-in to their website. I was then greeted by a request to give the "Sesame" code. For those who don't use LastPass on Linux (maybe other platforms as well), Sesame is an OTP generator, installed on the user's computer.
I was stumped. I hadn't copied the Sesame install to the new distribution. Luckily, LastPass provided me with a helpful link "Disable Sesame for this account". They sent me an email to confirm that I really wanted to disable Sesame, I clicked the helpful link, and upon next log-in, just my username/password were sufficient.
The LastPass enterprise administrators (people in the company with admin access to our LastPass account) did get an email saying that I had requested the deactivation of Sesame on my account. They were... "surprised" to hear that I did it myself.
Edit: typo.
For comparison, when I had trouble with Linode's 2FA - I set up a new phone and wiped the old one before realizing that Google Authenticator doesn't include TOTP secrets in iPhone backups, in effect destroying my 2FA token - and my scratch codes failed to work, I had to provide government ID matching my account information before their support department would disable 2FA on the account. I'm not overjoyed by the fact that an implementation error prevented my scratch codes from working, but I was pleased by the nature of the verification required to disable 2FA so I could log in again and re-enable it. Linode may have had some security problems in the last few years, but this at least they got exactly right.
Your email domain is a link in the authentication security chain for everything that'll let you send a "reset password" email. If someone can subvert your domain's MX records (by breaching your registrar account or your dns hosting, or by subverting the dns of the outgoing mail servers of the service they're trying to attack) then you've lost. If _any_ of those parts have weak authentication, your whole auth chain is weak.
(How much would you bet against me being able to change your cellphone account password and get your sms 2FA redirected if I can subvert the email account associated with your cellphone account? The OP is only lucky that his attacker wasn't quite sophisticated enough to attempt to take control of his cellphone account before firing off the Github 2FA SMS...)