First off, let me just say all your misconceptions stem from a very poor understanding of the HTTP protocol. You are obviously a 'tool user' and NOT a software engineer.

Otherwise you would never make statements like:

-'it's not even an issue' : This is a discussion about how API gateways bypass the HTTP protocol. ALL API's use the HTTP protocol. The HTTP protocol is implemented in every web server, framework, etc. So if it is not an issue, explain that to these companies https://venturebeat.com/security/report-shows-92-of-orgs-experienced-an-api-security-incident-last-year/#:~:text=Today%2C%20application%20security%20provider%20Data,Enterprise%20Strategy%20Group%20(ESG)

-'API catalog: it's really different from a solution to another' : Api Catalogs still have nothing to do with this. Api Gateways create their security thropugh a combination of 'connectors', security settings and OpenAPI. API Catalogs have ZERO to do with security.

- 'The BATCH scenario that you described can be handled by an internal gateway that handles a different rate limiting scheme' : As I stated 'unless you are doing it wrong'... which would mean with 'redirects'; doing it with redirect are not only twice as slow but EVERY SINGLE CALL goes outside the DMZ and thus can be intercepted or WORSE, the data can be altered on the way back in (see MITM). This is why 'internal redirects' are not only FASTER but more secure.

- 'Also it's not the duty of a backend server to handle that. It must be done somewhere before reaching it.' : Again you show your lack of understanding of the HTTP protocol. ratelimiting only needs to happen PRIOR to the response. Do you honestly think people weren't doing rate limiting PRIOR to API Gateways?????

And NO, this isn't a monolithic approach... monolithic is putting EVERYTHING in one application. Security is required. So securing something should not need excuses by people who do NOT understand the HTTP protocol to excuse poor implementations