Of course, I'd like to hear the argument against this. What are the downsides?
Scalability and performance issues. Imagine the situation:
your service became popular, so popular the 1 web-server couldn't handle it (yet 1 db server is enough). You bought two additional boxes and set them as additional webservers. As a simpliest form of load balancing you chose round-robin dns. Now, since the session state must be mantained throughout the farm, you have to implement centralized session storage. Natural choice would be to move session data to the database. And now, creating a new instance of an object is
less expensive process compared to re-creation of an object from session (because you have to deserialize it).
With any caching technique (and what you've proposed is merely a cache) arise the question: when to invalidate? Another mental experiment:
you use session as an intermediate storage in your multi-page wizard-like form. You accumulate a lot of data, but hesitate to store it permanently before the wizard is completed. Yet a user chose not to complete the form and navigated to another part of your site! That part uses session for its own purposes. Now every page of that part serialize and deserialize the data it doesn't need (session garbage collector will not touch that particular session because it still active).