It's not clear to me if the OP want's to run without any connection pool (incl. a built-in one), or just without a separate one.

In an ideal world PostgreSQL would handle infinite number of connections without a connection pool. Unlikely in practicem though.

There are good practical reasons to actually limit the number of connections:

(a) CPU efficiency (optimal number of active connections is 1-2x number of cores)

(b) allows higher memory limits

(c) lower risk of connection storms

(d) ... probably more

Some applications simply ignore this and expect rather high number of connections, with the assumption most of them will be idle. Sometimes the connections are opened/closed frequently, making it worse.

Eliminating the need for a connection pool in those cases would probably require significant changes to the architecture, so that e.g. forking a process is not needed.

But my guess is that's not going to happen. A more likely solution is having a built-in connection pool which is easier to configure / operate.

Separate connection pools (like pgbouncer) are unlikely to go away, though, because being able to run them on a separate machine is a big advantage.