Hi @GRAY Mike thanks for the question - as ever what you do or don't do is based on your requirements and appetite to risk. Threat modelling a given application/workload is considered a better way to guide decisions than (for example) a checklist that somebody relies on for all of their apps/workload (the point being apps and what they do are different so applying the same controls to all may not be appropriate)
Anyway, with that in mind, what you're talking about here is North/South traffic
(1) Ingress from the internet to your AppGW which fronts your web application AND
(2) Egress from your functions which establish outbound flows to the internet to both read and write data (push and pull)
Starting with the ingress
*Its perfectly fine to have App Gateway internet facing - it's been designed with that in mind. Adding a Web Application Firewall policy would give you extra protection (if you need it) against common vulnerabilities and threat detection. This may add more value than just having a conventional firewall as the WAF is working at Layer 7 and so it's working at the application level. I dont know what else you're using your App Gateway for.
*You can add a firewall of course for the ingress - however you should consider that for end to end SSL scenarios the Firewall won't see the traffic content - unless you either offload the SSL upstream or enable SSL inspection on the firewall, but for inspection to work the firewall will need to act as a "man in the middle" and inject its own certificate for the client (which can in some circumstances cause problems). Without this you would have the basic logging and ability to control SNAT and DNAT an restrict traffic etc. How much value does this add to your scenario?
*You can have both - but if you do this then I'd consider putting Application Gateway first (particularly if you have a WAF) so that the threat detection has visibility of the client ip
For the egress
The questions I would ask are: Do you have a strong dev ops and code review process? What are you trying to mitigate ? Do you want to limit public access? Do you want to log outbound connection? Are you worried about egress of data somewhere it shouldn't be (which in your case might be bad code if an internal employee is compromised, or even a supply chain type issue where you have a lib/dll reference which contains bad code)
If you wanted the outgoing traffic inspected then the same point as above would apply to the SSL inspection for end to end SSL.
As a side note: Keep in mind that unless you're using ASE (which is single tenant) then App Service doesn't allow you to add a self signed root cert to trusted store, you can only use what's already in the trusted store of the underlying VM Worker image.
For the functions to egress via an NVA/FW you'll need VNET integration per app and a UDR (custom route) to force the outgoing traffic to the firewall to egress.
For a wider discussion on the ingress options see https://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/firewall-application-gateway