The scope for:
Display and run third-party web content in prompts and sidebars inside Google applications
Is for HTML, CSS and JavaScript that "runs" from your browser.
The JavaScript code for that scope is inside an HTML <script> tag.
That's all client side stuff that the browser processes, and the browser is an app that runs from your computer.
Chrome is downloaded to your device, and runs from your device as opposed to from a server somewhere else.
I apologize if you already know this, but sometimes things are assumed and there is a misunderstanding.
You can do things from the client side code, like accept a payment, or send data to a firebase database without using server code, and therefore not need the "external request" scope. That scope is only for server side GET or POST requests. You can make GET or POST requests from the client side, and client side SDK's do that also.
As far as the security assessment charge goes, I highly doubt that Google would refer you to a 3rd party for the security assessment or charge you for that without your consent. I don't know that for sure because I've never done it, but I can't believe that Google can just send you a bill for $15,000 just because you submit for OAuth verification. The worst that could probably happen is that they'll tell you that you need the security assessment.
I guess what I'd make sure to do is to read any terms that you are asked to agree to. That's what the final authority is.
You can always click "Cancel" if you need to.
If they do tell you that you need a security assessment, then I'm not sure how you'd "get around" that. Unless you make your code open source, and charge for consulting and implementation work, then I don't know how you'd monetize it, if that's what you're trying to do. If you want it to be free, then you could just open source the code and tell them how to install it.
Unfortunately, the Gmail scope situation may prevent you from being able to publish the add-on.
If you could convince your users to create an Apps Script Web App of their own, that your add-on triggered, and then reads their own emails, that's the only strategy that I can think of that would work. They would need to publish their own Web App that read the email, and sent the content back to your add-on. But then your addon would need to be able to make an external request in order to trigger their Web App. And the user would need to provide the published URL to your add-on. I don't know whether that's a good idea or not, or viable, but that's the only thing I can think of if you really need to do more than just send emails, and they won't approve you.