It seems to me there are two different ways to handle Hibernate sessions in a Servlet environment. The first one is to create a new session for every request (as in the reference documentation section 1.4). The other approach is to put the hibernate session in the servlet session, and then to reconnect and disconnect for every request (as mentioned in section 17.3.1).

Is the disconnect/reconnect only meant to be used for a single "business transaction" with user interaction?
What is otherwise the advantage/disadvantage of each approach?

For a long time I tried holding on to the same Hibernate session in the HTTP session and connecting/disconnecting between requests. It was pretty much a disaster. :) I had lots of problems with stale Hibernate sessions and JDBC connections, even with JDBC pooling. When I started creating a new Hibernate session with each request I found no performance penalty. (The application I use it for is very low volume, though...)

So, my advice? Just let go. :)

What I'm doing now is holding a DataAccessWrapper (my own class) in the HTTP session. When a connection comes in I call the getDataAccessObject() method which creates an internal session, if necessary. I call the cleanupDataAccessObject() method when I'm done. (flushes and closes the session, then sets it to null.) I could easily shift back to maintaining a Hibernate session all of the time by changing the behavior of those methods. Try it and see which works best for you.

It is very dangerous to store session in httpsession.
1. resources are wasted (memory and DB connection)
2. all objects stored in htpsession must be thread safe, session is not threadsafe.

BTW it is not a problem to close phisical connection at the end request too, if you do not open connection more than once per request.
some of my applications are more scalable without connection pools
on "big" machines (a few GB of memory, separate disks with optical interface for system, data and logs). Sometimes pooling intoduces more problems than optimizations.There is no optimization in some tests, but it depends on things like DB authentication configuration, "aggressive" cache and resource management in application.

Is this really necessary?

In theory it must, but it can work without problems in practice.
It can be a few concurent requests per session: frames, images, ... are sometimes dynamic (or can become dynamic later after UI changes),
some script can open a few windows too.