Is it a good practice to avoid using Session State in ASP.NET MVC? If yes, why and how?

It's not explicitly written somewhere but I felt so after reading few blogs on ASP.NET MVC. Just got curious and thought of asking it here.

UPDATE:
I'm not asking about memory/storage/RAM concerns on server. For them, there is a solution to store session out of process. I know that. I'm curious that, are there any scenarios where we had to use Session in WebForms but we can avoid it now in MVC taking benefit of the nice structured way offered by MVC?

In ASP.NET Web Forms, passing information between different pages was never especially easy without the use of session. Due to the postback-centric model, information was available on the server as part of an event, but often in the wrong page for displaying a result, making passing information between pages necessary.

This tended to lead to an overuse of session, populating "current" variables in session intended to indicate what the current object being interacted with was. This overuse in turn made applications very state-dependent and much harder to determine expected behaviour ("Is this variable populated?" "Do I have the current order ID yet?").

MVC is structured around the idea that your website is a view into a logical model of information. It encourages having stateless operations through the use of simple controllers responding to actions with key information passed as part of the HTTP request.

Because of these properties, session is no longer required to perform basic tasks in MVC, and becomes poor fit where it has seemed a perfectly valid choice before.

Fundamentally, session pollutes HTTP. It makes requests (often containing their own state) dependent on the internal state of the receiving server. This is why it's seen as something of an evil (although often a practical and necessary one).

Session was avoided even before MVC, because it's info that gets persisted on the server for each of the users that connect to your application and (unlike cache) is not erased automatically when not used.

Also in order to help you avoid using session, ASP.NET had viewstate, which was actually a huge hidden field in your webforms that got POSTed on every postback. This too was too clumsy for various reasons and was dropped with MVC.

So session is actually something that was not very recommended even before MVC. The reason is mostly scalability. The less state you persist, the more scalable your site will be. If you don't care about scalability (for what I know you might be developing an intranet application for 200 users) or if you have very little info to persist by all means do use session. In other cases, using session is entirely appropriate: a typical scenario where session state is used is the shopping cart in a ecommerce site (info which is inherently per-user per-session and that only a percentage of your users actually have populated).

As for the alternatives,there is not a direct, drop-in replacement for session. Depending on what you're trying to do you may be able to use cache or cookies. MVC has not brought anything particularly new in that regard, AFAIK.