>Firstly, although I don't know exactly what they do these days back when the system was implemented adding 2FA would disable the risk based auth system and make logins purely deterministic, at least after some time had passed (account hijackers liked to add 2FA as the first step in locking down an account after taking it over, so full security didn't start immediately). So unless that's changed he can get what he wants just by using 2FA.
Funny thing, I actually surmised that a lot of services work like this for some time. Interestingly for services the security of which I don't care about and which don't warrant my actually provisioning an air-gapped 2FA token, I often turn on 2FA anyway and just (pointlessly) keep the TOTP secret in the same password safe as the account password.
Why? Because it seems to be treated by a lot of services as a flag to a) disable non-deterministic authentication, and b) as a flag to disable password recovery (or at least make it moot if you can't also recover the TOTP secret). I consider the former actively desirable in all circumstances, and I consider the latter desirable because I have enough confidence in my own credential storage practices that I'm more than happy to accept the risk and responsibility of being locked out if I lose that token.
But this is an unofficial hack. It's not like it's a documented commitment. One basically is crossing one's fingers and hopes that enabling 2FA is some kind of secret trigger to disabling risk-based auth, and I don't really have any way of predicting with confidence whether Google (or any other company doing nondeterministic login) will silently change this later. I want a deterministic login system which is well-documented enough that I can determine ahead of time what set of credentials are sufficient for access.
You are correct that Workspaces makes things much better. I think to address everything in article though, that would need to be combined with documentation as to everything the authentication process can conceivably throw at a user, combined with a firm commitment to an advance notice period before any changes to that process. The discrimination against some browsers also needs to be addressed, for example, is this disabled for Workspaces, and more importantly, does Google firmly commit not to apply this sort of thing to Workspaces in the future?
>Phone numbers
Funny thing. I have an original invitee Gmail account registered 2005 that I can't access anymore because any attempt to login to it causes Google to demand a phone number. There is no phone number associated with the account, rather, it's simply a demand that I give it any phone number, so this can't possibly serve any account security purpose. This seems to me like a raging GDPR violation given that it's essentially an attempt to extort more personal information out of me by holding the account hostage, as well as denying various GDPR rights, like account deletion, subject access, etc. I refuse to use a phone number in general.
>Is it better to lean towards allowing access or lean towards denying access?
You paint a compelling doomsday scenario but the same can be said in another direction. Here's an interesting hypothetical question: if a SaaS (for example) company lost access to all its cloud accounts, but billing kept working and their service was still up, meaning the service still works 'for now' but no changes can be made to it, how long would that company last?
But even this question is a distraction. The real problem here is the lack of legibility of the authentication process, i.e., documentation. I can't predict what the authentication process will do, now or in the future. That's the problem. My best efforts to understand the Google Accounts system (mostly by reading between the lines of how the system works) leads me to the conclusion of this article that I do not have any confidence that it will let me in when I really need it to. That's fundamentally a product marketing and documentation issue more than anything. It could be rectified with authoritative documentation on necessary and sufficient conditions for authentication with a commitment to notification before any changes, at least. It should be possible for me (a non-Googler) to understand the necessary and sufficient conditions for authentication and make my credential arrangements accordingly. But as things stand the system seems to fundamentally lack this property of legibility.
Legibility is important because it gives me the user the power to choose whether I care more about account availability or account security. For example, suppose I enable TOTP on account A. I decide that the lack of availability of access to account A poses more of a risk to me than illegitimate access, so I make three backup copies of the TOTP secret and store them at three separate locations. Since there are three copies, the risk of one of them being stolen is obviously higher than if there were only one. On the other hand, suppose I decide account B poses almost no risk if access to it is lost, but illegitimate access poses a great risk. For this case I might have only one copy of the TOTP secret to reduce the risk of theft.
This is an oversimplified, abstract example but it illustrates how legibility of an authentication system's necessary and sufficient conditions for access allows the user to make an intelligent arrangement regarding whether they want to bias their access towards availability or security. I can't do this with a system which is opaque as to what it's going to ask of me in the future. The system will either ill-serve people whose greater risk lies with lack of availability, or ill-serve people whose greater risk lies with lack of security.