The thing to remember is that a session is little more than a map full of references to objects on the heap. In other words, the session itself takes up very little memory.
Once you understand that, it should be pretty easy to picture how your use of sessions will affect your app under different loads.
If you have a high volume site, especially if most of the users are only on your site for a second or two, it wouldn't make a lot of sense to load up a session that is going to hang around for 30 minutes with megabytes of data.
Picture how much memory it would take for Google to cache all of your search results in session.
If, on the other hand, your app has a lot of users who log in and then stay on your site for long periods of time, and possibly perform the same functions over and over again (a payroll entry application for instance) then you might actually be able to save memory, reduce the number of times the system needs to run Garbage Collection, or reduce Database IO by caching frequently used objects in the user's session so they don't need to be created and populated over and over again.
On clustering:
If you're using session replication to cluster your app, everything written to session has to be replicated (usually with
Java Object Serialization over TCP/IP). This is work that your CPUs and network will have to handle.
It also means that clustering won't really change your memory requirements because all of the nodes in the cluster will have to hold all of the session objects.
Like most design questions, the answer is "it depends".
