I happily use 40+ accounts per service, and don't think it's an undue burden. Accounts are free and represent a convenient natural boundary for data, access, and oopsie-daisy mitigation.
"Undue burden" and good UX is a wide chasm. In the last few months of my last role we went from the 1 account to multiple separating environments and the additional cognitive load and extra work migrating was not trivial (plus trying to keep costs down duplicating things for migration).
I can see how starting with a pattern of "account per X" would create intuitive boundaries. When you say "per service" what kind of service do you mean? Business related web service API? AWS product? Other? Interested in what boundary line made sense for you given the large number of accounts you say you're happy with using.
I would say one account per business-related Web service, per stage, is a sensible way to break it up. That gives you some visibility into what services are talking to what other services, logical cost breakdowns, and access controls pretty much where you'd want them.
I can see how starting with a pattern of "account per X" would create intuitive boundaries. When you say "per service" what kind of service do you mean? Business related web service API? AWS product? Other? Interested in what boundary line made sense for you given the large number of accounts you say you're happy with using.