It's the same in AWS with AWS SSO/IAM Center. You only login once, and you can access every other account (project) you're allowed to access.
The best part is that the account is in the URL so you can just link to specific resources in different accounts. So many of our runbooks for GCP are like "click this link" whereas for AWS it is "make sure you are looked into {specific-account} then click this link". The latter is much more error prone and can break your workflow if you were doing something in a different account previously.
Edit: I realized you are talking about switching accounts twitter style. I don't mess with that - I use a separate Chrome profile. Also you are arguing for GCP, I thought you were arguing against it.
* Having separate accounts, not being able to have separate accounts - I know it's possible with AWS as AWS doesn't force you to use a single account.
GCP’s IAM somewhat addresses the isolation and scope problem mentioned in the article. Not all GCP apis, atleast with respect to OAuth2, properly utilize IAM, insofar that they require overly power OAuth2 scopes. For example, to list cloud functions you need permissions to create and edit, too. That’s broken.
In GCP, many orgs find themselves proliferating in projects because GCP’s billing is abstruse. People isolate resources to projects so they know how much specific services actually cost. This in turn presents another problem. GCP Web Console’s search doesn’t index well. For example, substring search doesn’t work on far too many resources. VMs are the exception, but we think this is inverted. Substring search should work on every resource, not be exceptional. Historically it didn’t even do cross project search. This is frankly not acceptable for a search company.
Do you have a concrete example of that? Or, maybe you mean the console needs those perms to work?