On the topic of not restarting your web server after making changes: more interesting to me is parallel sessions running different versions of the server code. New sessions coming in get the newest version of the code, while older sessions keep running the old code, for an arbitrary (configurable) amount of time. This was a property of a system I was part of building in a previous job, and it worked very nicely; all session state was in a tiny (<64K) blob of data which contained in its header a pointer (intranet URL) to the server application metadata. In an ASP.NET environment, this made minor upgrades to the app server software painless, with no need to partition the web farm, bleed out old sessions and bring up new sessions, etc.; it's all automatic.
I have trouble believing that "no shared state" and "reloading your code with every execution" can possibly be an advantage in production.<p>Maybe when you're developing, sure, but they otherwise only force you in to inefficient workarounds.<p>Of course, the statelessness of HTTP contributes to the necessity, but using a proper language (there, I said it) doesn't get in the way of creating a proper server application.