Many application servers have connection pools integrated, and even standalone applications can be configured for use one like HikariCP, Apache DBCP, etc.
So what is the advantage of using PgBouncer when the application already have a connection pool?
The most close answer I found is What are advantages of using transaction pooling with pgbouncer? which do no mention the use of another connection pool and mentions that the advantage is the idle sessions usage.
I primary use WildFly configured with min pool size, max pool size, idle timeout... so it essentially removes idle connections when they are not in use (if that it's the main advantage).
This makes me think that PgBouncer don't fit in this scenario and I just should keep using my application server connection pool only.
BTW, in transaction pooling mode, PgBouncer can't use named prepared statements which don't look like a performance wise choice.
If there is any advantage, do it plays well with the wildfly connection pool?
If your application server has a connection pool included, and there is only one application server connecting to the database, it is better to use the integrated connection pool.
In such a scenario, pgBouncer would just be an extra component that makes the architecture more complicated, and you'd have the extra overhead of all the connections between the application server and pgBouncer.
If there are several application servers that connect to the same database, the question is not so simple any more. If there are just two or three application servers, you might live fine without pgBouncer.
The more application servers connect to the database server, the more database connections you will have, and this puts the database at risk: if too many of these connections become busy at the same time, your database performance and response time will drop, since the database is overloaded. In such a case pgBouncer will help by limiting the number of active connections to the database.