In my current adventure of learning hibernate and setting it up to use an appserver's connection pool, most examples and resources out there point you in the direction of binding the SessionFactory to a JNDI resource in your appserver in the process.
I wondering what the benefit of this is? Since the you can access a the connection pool with out doing this.
The same reason you'd use JNDI for anything, I'd say - moving the configuration out of the application, into the deployment environment.
With JNDI, you basically say "this application needs a SessionFactory; and its name shall be X" and you're happy as long as the application server has a SessionFactory called X configured. This kind of externalization has several appealing benefits:
You can use wildly different configurations on different machines (production and QA use Oracle, developers use HSQL, ...).
You don't need to make your build process aware of configurations (no more ant war_for_qa or screwing around with Maven profiles).
You're not tempted to check configurations into version control, and so your live database password won't be known to every temp, intern, consultant or ex-employee who's ever had (or will have!) access to the repository.
Your installation/configuration instructions won't include items like "to configure the database login, edit the file foo.properties in the WAR file" which will inevitably result in configurations being overwritten on the production server at the worst possible moment because a sysadmin who's been working all weekend happened to deploy a non-edited WAR because the coffee ran out on Sunday afternoon.
JNDI just happens to be the "standard" way of doing this externalization in Java, which means that new devs/admins won't need two days of training to learn the quirks of your own, home-brewn configuration system which really is quite clever but has this weird bug no one wants to delve into because it's really weird and anywho it has a pretty simple workaround, &c.
Related: What is the purpose of JNDI?