Yes, I've done a variety of typical, nontrivial workloads on Postgres for about a decade and have never used PgBouncer. Though I can imagine use cases where it'd make sense.
1. Typical backend with a DB, serving either a web/mobile app or other services within a company. Each job had a pool, so there's a steady number of connections to the DB that didn't exceed what it can support, with some headroom for monitoring, cronjobs, and emergency access. Xacts were usually short. Was able to handle high QPS, and when it hit the limits, it was something on the DB rather than backend CPU starvation, so adding more backends and thus connections wouldn't have helped. Even though some of these were on Heroku which has a rather low DB connection limit.
2. Data pipeline that used Postgres queries as sort of a map-reduce. Not ideal but I think not that uncommon. Each machine had a local DB with mostly temp tables, plus there were some shared DBs. Each running stage in the pipeline needed one connection per CPU core because queries were sharded that way to utilize all cores.
3. Another data pipeline that used batch workers that did their bookkeeping in a DB. This was infrequent enough access that I had each one opening a connection right before using it then closing it after. PgBouncer would make sense there, but we were fine even if every worker opened a connection at the same time. That's partially because many of those workers were GPU instances, so there weren't terribly many of them.
I'm actually wondering who is in situation #1 and needs PgBouncer, and why exactly. The scenario I have in my head is you're doing heavy CPU work directly in your web workers, and thus you need more workers than you have DB connections available, which seems like it's more monolithic than it should be.
