Mike Brunt just posted the latest in a series of articles about high-availability web site architecture, with the conclusion that "the most effective Load Balancing in a Cluster is Round-Robin with Sticky-Sessions, if it is necessary to preserve state in a single user session."
The later portion of which would seem to be an interesting qualification.
After all, why would someone use memory-based sessions in an application meant to reside in a high-availability environment?
If your web site requires multiple servers (MSs) and load-balancing hardware (LBs), then restricting users to a single device would fall under the definition of "a bad thing".
First up is the obvious reason. If a server fails or is taken down for maintenance, then any user assigned to that server is hosed.
Second, if your traffic levels are that high, then it's possible your server could be maintaining thousands, if not millions of sessions over a given period before they timeout and are deleted. While RAM may be relatively cheap, there's a limit to the amount many servers can actually use.
Especially those based on earlier JVM's.
The solution? Manage session state via a database (client variables) or by using a dedicated application server cluster.
One reason often quoted for maintaining single-server connectivity are SSL-based transactions and the high overhead that can be needed to initiate a new session.
If that's an issue in your organization, then make sure you find the right hardware. Kemp, for example, will offload SSL encryption to the LB system using dedicated hardware.
This lets your servers do the job of processing transactions, and not let each one spin its wheels doing the extra work of encrypting content (often a 30-40% hit).
Offload SSL processing, and a three-server farm could easily do the work of five.
Always take a hard look at any "requirement" for session-based systems. Especially when scalability is an issue.