Understanding the article may require a bit more context than was given. The author is talking about Session objects within a Java application server (e.g., Tomcat, Weblogic, JBoss, etc.) Such a session is a funny beast. The application has to explicity ask for one during the processing of a request (which would typically be an HTTP request). This results in the generation of a session key, and the creation of a object (the "session" object) that corresponds to that key in which information that applies to that session can be stashed. The key is communicated back to the client by either session cookie or by URL rewriting (the key gets tacked onto URLs), and is presented to the server on subsequent requests. If an application stuffs stuff into the session object, that information will persist across requests.

There are two bit problems with using a session object:

1. Sessions expire. Either by timeout or by application server restart. If you hang state off of a session object, you can lose that state. This is usually very bad.
2. Unless you're careful with bookkeeping, a state object can accumulate a lot of cruft. This can act like a memory leak, at least as long as the session persists. It can also be a data consistency issue, if you're caching stuff in the session without checking cache consistency.

In Java app server land, the standard advice is to avoid using the session for anything other than a cache, and to pass a cache key in via session cookie or URL/form parameter. This allows the application to validate the cache, and to rebuild the cache if the session has timed out, or if the server has been restarted while the browser user wandered away for coffee. This advice isn't Java-specific. In any system that keeps sessions that can be timed-out, it's unsafe to do anything other than use the session object as a cache.