The point was that this was always a choice - there has never been a point where it was required. My first ISP back in '93 ran mail, web, ftp and shell accounts on a single pc. So did the ISP I cofounded in 95. It isn't and never has been a technical limitation, but a choice down to what worked for you. Especially as address rewriting firewalls also existed back then, so multiple services pointing to the same external IP in no way implied they had to be the same physical host.
For us (early regional ISP, mid-'90s), a lack of separate per-service hostnames caused significant scaling fragility.
In the initial rollout, all services were served from a single physical host with just one listening IP, which the bare 'example.net' resolved to. (Was this naive of us? You bet.) Other service hostnames (www., smtp., etc) were all just either CNAMEs to that hostname, or A records to that IP.
When our SMTP usage started to exceed the capacity of that single host, we tried to move 'smtp.example.net' to a different host. This is when we we discovered that many users were configured to use 'example.net' for SMTP instead. We had to update all of those users' configs before we could turn down SMTP on the original host. (We couldn't afford big-iron load balancers, and they were less common then - we just used DNS round-robin for load distribution).
At that point, we realized that customers were using bare "example.net" for everything - homepage, SMTP, POP3, IMAP, FTP, DNS, shell access - you name it. It was easy to remember - and it worked. So it was hard-coded everywhere - FTP scripts, non-dynamic DNS settings, etc. And this was looong before email clients had automatic configuration detection, so that was all hard-coded, too.
So we had to painfully track down all the users who were still hitting 'example.net' for SMTP, and help them update their configs before we could turn down SMTP on the original ancient host. The other services had to go through a similar painful transition.
We concluded that the only way to prevent this from happening again was to make sure that the bare hostname never offered any services at all - except for a single HTTP service whose sole purpose was to redirect 'example.net' to 'www.example.net'.
From then on, each new vISP domain had the same non-overlapping service namespace ... so that the otherwise inevitable configuration drift would be impossible.
Later, with the rise of things like email autoconfiguration, load balancers, and POP/IMAP multiplexors (like 'smunge'), we had more options. But at the time, avoiding services on 'example.net' was the only way to go (for us). Having a bare 'example.com' as the sole hostname in the browser bar was a sign of brokenness. :)
I wasn't claiming it was a technical limitation or a requirement, just that the time where this happened certainly did exist. Choice or not, the time existed. That was my point. Fair enough.
