But if you are a browser extension I would have expected you wouldn't need your own permissions at all: you would either be scripting the UI of the client to accomplish your goals or stealing its authentication.
As someone with a lot of experience in working on a Chrome extension that interacts with Gmail specifically, there are two reasons I'd expect an extension like OP's to integrate with the official Gmail API instead of poking the Gmail web app's internal API directly: 1) the official Gmail API is stable, documented, and doesn't take reverse-engineering to use, and 2) the Gmail web app's internal API is pretty strongly rate-limited for some actions.
If an extension only does actions involving the UI and data visible on screen within the Gmail webpage at a regular user pace, then I wouldn't expect it to strictly need the official Gmail API much. But this would mean the extension can't operate on emails that aren't on the current visible page, etc.
Tbh I didn't really consider this approach as I didn't think it was possible (that's if it is). Also I'm not so comfortable with hijacking authentication session. I very much prefer making the user actually grant permissions to the required scopes and making it clear what the access is used for.
I mean, we can argue lots of things, I guess ;P, but an extension already has access to that authentication token, and pretending otherwise is a bit... "performative"? The expectation I have with an extension--as someone who used to manage an entire ecosystem of such extensions of native software for a decade--is that it is a true extension of the application that it is extending, similar to if we had the original source code to patch.
