Well, all databases have some connection limits in the end. With Neo4j it's common for people to use similar approaches (for example deploying lambdas, or microservices that "front" the database with an auth layer and allow a limited range of queries to be executed). Another popular option for Neo4j is to expose a GraphQL Layer (GraphQL Library: Open Source Graph Library for Rapid API Development) which the serverless web apps then use, it's pretty convenient and quite flexible.
Under the covers, the way the GraphQL layer works is that it manages Neo4j driver instances, which have connection pools. Because all databases do have a certain number of connections they're limited to, those intermediate layers (whether it's a lambda or a graphql layer, or a REST API or whatever else) have to choose to either slow down requests or spam the database. Throttling requests is the better choice.
This isn't too much of a concern though if you're using Aura Pro. By default those instances are backed by clusters, and for a decent instance size, many many thousands of concurrent read requests at the same time should be fine. These typically go pretty fast too because (for the right instance size) a lot of data is hot cached in memory. One of the things that alleviates the connection limits in a graph database is faster response times (meaning fewer connections tied up for less time, and less of a "traffic jam") -- compare that to doing complex expensive joins on another database, where connections have to work harder, longer.
