In the context of Web or application servers, state is basically the temporary persistence of some information-either general or specific to a session being executed on the server. Generally, the more state an app maintains, the less scalable the app becomes, because precious system resources are being tied up in activities such as database connections, database transactions, and memory consumption. This has led to many discussions about the desirability of statelessness in development, especially with app servers such as Microsoft Transaction Server. On the other hand, jumping through hoops to obtain statelessness may produce a cure worse than the bite. Educate yourself about the implications of keeping state.
Many developers use the session object to store state between pages.
Most of this state is unnecessary, and many times it isn't cleaned up properly. Suppose you have a page that would let your customer service user enter a last name and view the matching records on an ASP page. The user would then change the address of one of these customers by selecting that customer from the provided list. If the customer service rep isn't going to continue using this list of customers, don't store this information in the session object just to display the address from one record on the next page. Using the session object to store state is really a judgement call.