This is base of pgBoouncer or any pooler software - the main work of pgBouncer is reusing PostgreSQL connections. Creating lot of connections can be very expensive for short sessions - with fast queries. When physical connection can be shared (reused) for more clients, you can get much faster execution.
Second important role of pgbouncer and similar software is a protection against overloading. PostgreSQL has not internal pooling - any connected user can run any SQL. There are lot of applications with long idle connections. These applications requires high
MAX_CONNECTION number. Hidden assumption is low activity on these connections. But sometimes can be pretty high activity, pretty high requests on new connects and the database can be overloaded. The
MAX_CONNECTION should be about 10 x CPU cores. Inadequate value doesn't protect database against overloading and finish by failure. For these application can be pgbouncer safe solution - this software is able to share physical idle connections for lot of clients.
server_lifetime enforces returning allocated sources to operation system. Some sources (like memory) is internally managed and it is newer returned to operation system (usually). Some memory expensive operations can require lot of memory. First time this memory is allocated from system. Next times this memory is managed by PostgreSQL only - it is much cheaper and faster. But sometimes it can be ineffective too. pgbouncer has not information which process has preallocated memory - and sometimes memory can be used better. The safeguard is
server_lifetime. One hour is conservative value - and can be shorter - 10 minutes. pgbouncer close only not active connection - so if the connection is used by any client: opened transaction, long active command, ..
server_lifetime cannot be applied.