Most likely, it "worked" in 6.0.20 because of a bug that got fixed by release 6.0.29.
The whole reason for the rigamarole about Underlying Connection is because the actual
JDBC Connection object that links to the Oracle server is not what gets returned from the connection pool. Instead what you get is a delegating extension class that mostly hands off all its method calls to the underlying (Oracle) Connection, except for the "close()" method, which simply returns the connection to the pool instead of actually severing the network linkage as the underlying Connection's close() method would.
There is really only one reason for obtaining the underlying Connection object, and that is so you can invoke methods that the underlying Connection object's driver provides that are not in the
Java JDBC standards. While this can be useful, it is not something you want to do for trivial purposes. It locks you into a specific vendor, both in terms of the actual code, and in terms of where you can get support. Unless you absolutely, positively must, I don't recommend tying yourself to any vendor, even one as well-established as Oracle. You can never tell when someone in Accounting will balk at sending Larry Ellison another $100K and require you to dump your application on a PostgreSQL server instead, for example.