Also helps when you may be changing what you're doing. You know all that annoyance you currently do with NGinX and Apache and whatever else where you write a very cryptic config file telling it what runs on what ports and in what directories and how to serve it? I would love to do less of that. I would love to not have to change it every time I put up a new little Ruby-on-Rails toy web-app. I would love to be able to just shove a new Rails or PHP or Sinatra or Node.js project into my github repository, have a simple cron job on my server check it out into my "checkouts" directory, and then not have to configure the web server for it.

These things are doable with current servers, of course. They're just a pain and involve writing a fair bit of code to make it happen. If you could subtract the "update your NGinX/Apache/whatever config" step, you'd eliminate a fair bit of the current friction.

This is more important for hobbyists than big sites. A really flexible server will never be quite as fast as a fully dedicated server (cf Mongrel_cluster versus, say, Passenger). But for hobbyists, it could be a godsend.

Newer hobbyists won't even have to learn how to deploy a Comet/FlashSocket/Websocket server from behind a reverse-proxy. I envy that.

Yes there are firewalls/proxies which check for validity of HTTP over port 80, though others don’t bother, or just look at the first bit of traffic for each connection.

HTTPS goes over port 443, and I imagine there are some firewalls somewhere or another which block it altogether. Probably not enough of them to worry too much about though.

Some firewalls at least make sure that traffic over port 443 does a proper SSL handshake.... after that the data is encrypted, so they have no way to tell just what’s going through.

Some firewalls can track this.

It increases reach. Millions of people are behind firewalls that only allow HTTP traffic.