Following "it was done this way for a reason, even though it might not make sense", what was the rationale behind some of the defaults/decisions Microsoft made in their NT4/2000 days?
The complete opposite of something like OpenBSD where most everything is disabled by default.
They listened to their customers. Which is often the right thing to do, but rarely when it comes to things with security implications, but it's fair to say that in general the tech industry was still fairly naive back then.
Win2k came with IIS enabled by default, etc. etc. etc. It was a security disaster. Microsoft decided from the next version on that convenience didn't trump security and went back to requiring you to consciously turn on services.
It took some effort to get people at Microsoft to start seeing things from a security perspective. The work Michael Howard (who wrote the "10 years since the BillG memo" article 'twoodfin linked to below), Jeannette Wing, and I did on measuring attack surfaces was part of this -- trying to quantify, even roughly, how big the attack surface was so that there could be explicit goals to reduce it. You're certainly right, though, OpenBSD was way ahead of their time here.
Back then, "enabled by default" was the rule. I recall Linux distributions of that era also enabling a lot of network-facing stuff by default.
For Microsoft in particular, there's also some path dependence: they began with non-networked (or with local-only networking) desktop operating systems, where the drawbacks of default-enabling many useful services were not as severe.
Windows around the same time, maybe a few years later, was much worse though. They actually had to patch a bug where the system would boot after install and the firewall might not come on until a second or two after the network, and there were so many exploits and worms that systems were getting exploited in this very short time-frame.
How risky it is to have a feature enabled by default is a function of
a) The complexity of the feature.
b) The reliability of your development and testing process re: security.
and
c) The ultimate severity of any vulnerability.
At the time Windows 2000 was being developed (late '90s), Microsoft tended to systematically underestimate a) and c), while overestimating b). Then came an internal push for better security practices and billg's "Trustworthy Computing" memo. There's a good discussion of it and the consequent sea change here:
http://www.zdnet.com/article/10-years-since-the-bill-gates-s...
After Blaster, and 4 roomates wiping our gaming PCs, I stole a copy of RHEL and used that instead. It was a lot harder to configure; you had to know what you were doing. I managed to squeak by with settings remembered from Win2K, but others may not have fared so well.
This is fine for OpenBSD, you are assumed to know what you are doing when you install it. But Windows gets installed for all sorts of people, many of whom will tell you to your face that they are "not computer people", and will be very annoyed when the OS doesn't magically do what they want.
Of course it was!
You must be thinking of the split between the consumer-oriented Windows 95/98/ME and the business-oriented Windows NT/2000.
The parent comment used "consumer" in another sense: an "I am not a computer person" end user. Windows 2000 was certainly intended to be fully usable by these kinds of consumers, at home or at work.
And the comment was more general than Windows 2000 - it is really a message to people who are designing OS features today.
I think many people attempting to sell into business don't quite realize that there are novice users there too. Ease of use, ease of deployment, and maintenance without a highly technical internal supporter are critical issues that products with massive business adoption have to get right.