You got the point.
1) Session variables are stored in session state (there are different support mechanisms for that), and they are meant to be the mean of separating sessions (:)) identified by a session id. In general a session id is a cookie, that is generated by the server, sent to the client, and the client is sending it back with every request. Thus you can store client specific data in it (but not too many). When a session is abandoned from code or it is timed out, the session id and the session state is destroyed, lost forever. But there is a thread related to the sessions, called session hijacking, when an attacker is stealing/guessing the session id of an other client, thus entering hes/her session, and having access to what the other client has. In this context a client can be a named or an anonymous, ad-hoc user.
2) Session variables are used for keeping value across the session. Thus it is a waste of resource to use it for storing something that is necessary during processing of a single request.
But ASP.NET processing pipeline is more complicated than simple CGI (as PHP for example), I suggest you read this article for a deeper view:
http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp[
^]