Charging per request for something that has a cost to provide is reasonable (and it's a tiny charge in this case, $3.50/million or 0.00035 cents per request).
Otherwise there's no incentive for application developers to optimize their usage.
In my last company we charged per unit of work, but it was possible to send a lot of requests to do a tiny amount of work -- some customers hammered us with millions of requests to do each unit of work. It wasn't malicious and it worked with their workflow, but we lost money on those customers due to all of the infrastructure required for the request routing.
The company eventually started charging a nominal fee per request, which resolved the issue.
I don't necessarily disagree with you, but I don't think that's a strong example. Charging for utilization is the most obvious way to price a service, and http requests are the most obvious way to track utilization of an API gateway (or any load balancer).
I've never used AWS so perhaps I'm mistaken, but api gateways normally provide extra functionality on top of just proxying the request. You can still set up a server listening on port 80 or 443 with a public IP and make requests to it without being charged per request.
You can, and if you want to use Lambdas, you can also route to them from ALBs, which has a bit confusing of a pricing model for comparison, but has no per-request cost.
Oh, ALBs. Now that's a mess. You'll either be charged per new connection, per concurrent connection, per byte, or per rule evaluation, depending on which is highest any given hour.
