Lots of people are pointing out that with the Host header one web server can handle multiple domains. Yes, that's true.
It's be useful in cases where you have one organization that hosts multiple domains. Then you just configure your server to handle this domain this way, and that domain that way, etc.
But it doesn't help the cases where you want to host multiple, unrelated websites on one server. Let's say Acme Widgets has a static site that just serves files off the filesystem, but they've got a bunch of rewrite rules to handle legacy urls. Umbrella corp wants to run a node backend. To get that to work, you need to agree on a server that will handle the requests. Everybody needs to be able to configure it to their liking, which leads quickly to the cPanel scenario I mentioned above. Or, hey, we can automatically configure the shared server as a proxy and let everybody run their own servers on non-privileged ports! That works, but it introduces unnecessary overhead in terms of memory, CPU, SPOF, latency, configuration etc. It would be better to just have the browser connect directly to those unprivileged ports!
tptacek brings up the good point that lots of networks block connections on ports other than 80 and 443. That's true, but it's because of the fact that HTTP essentially has to use those ports. If the web started working on other ports, that would change. Slowly, yes. Port 80 would have a special status for a long time. But if the standards did support other ports, network administrators would have a hard time answering "Why can't I connect to acme.com?" with anything other than "oops, let me fix that". This would be a way easier transition than say, switching to IPv6.
Finally, I'll reiterate that none of these problems are insurmountable. The web exists because we've found ways to work around them. A lot of use make a living doing just that. But that doesn't mean this is the best way of doing things, or that the work-arounds have no cost.