Standard practice in larger scale.

I run big fleets, 100s of hosts 1000s of containers in most AWS regions. Most of the control plane is automated, but when that breaks, or there are issues in the data plane, I might log into read logs, look at metrics, force scaling actions, or just general investigation tasks.

I also use different accounts for permissions boundaries. Data shared between multiple teams might go in one account. The apps can access the data but maybe the interns can only access the app account while the SR. Eng(s) + current oncall have full read only access to the data for investigation. A second RW-Data oncall might have access to the DB account in each region. Ever data storage account also has a limited access cross account Data replication/backup account.

+ I help people out. 'Can you look at this? . . .'

In the end, there are account specific errors that can be caused in your infra, IAM rolls, keys, throttling, malicious access that are easily prevented with least access in per account buckets. So I end up with multiple accounts in each region.

It's not that unusual to use separate AWS accounts as blast-barriers. I.e. they contain the damage that might occur due to a leak etc. I typically use 2 (prod & non-prod) for each major product/offering, plus a centralised one to manage policies, billing etc for all the sub accounts. They add up pretty quickly.

My employer has accounts in the hundreds...

Similar to OP you're replying to, I use Firefox Containers to open separate accounts to open independent windows from my Identity Provider when I need to be in more than one account at a time.

AWS credits? You can get a bunch of free credits for each account, and then build an abstraction around boto3 to make 20 accounts look like 1 account to you.