Now this person is somewhat younger than I (ok, most everyone in the industry is somewhat younger than I), but he is a super smart guy.
The thing is, he has NO CLUE about how the personal computer world operated back in the early 80's when Windows was designed. Windows was designed to run on machines with 512K of RAM, on machines with a 10M hard disk. In addition, the CPU on which Windows was intended to run didn't support memory protection, so the concept of "separation of privilege" was meaningless. MS-DOS (on which Windows 1.0 was built) had a long history of putting critical OS information into an application's data space. For Windows, things were no different - the line between application and system was often blurred.
Whenever there was a possibility of offloading potentially optional functionality onto the running application, Windows took it. Instead of having a preemptive scheduler, Windows used a cooperative scheduler. That meant that applications never had to deal with ugly issues like synchronization of data, etc. The consequence of this cooperation was that a single errant Windows application could hang all the running applications.
But that was ok, because the overhead of the infrastructure to FIX the problem (per-application message queues, etc) would have meant that Windows wouldn't be able to run on its target systems. And adding all that extra stuff really wouldn't make that much of a difference since the applications were all running in the same address space (along with Windows and the operating system).
So it's not surprising that there were a lot of things present in the early versions of Windows that would make people cringe today. Sometimes this isn't a problem, but one of the key values of the Windows platform is that Microsoft very rarely intentionally breaks applications. We'll break applications when the applications depend on a security flaw, and sometime applications will break when there's a fundamental architectural shift occurring (we already know that some multimedia apps are broken in Vista because they depend on being able to call multimedia APIs during DLL initialization, which only worked by luck in XP).
But barring that, Microsoft's made a strong commitment to not break customers applications. The good thing is that it means that the Windows platform is remarkably stable. Many applications written for Windows 1.0 still run on Windows Vista. It means that corporations that have made an investment in technology aren't going to lose that investment by moving to a newer version of Windows. It also means means that every version of Windows carries forward the designs from previous versions.
If there was any "mistake" made, it was Microsoft's unceasing commitment to backwards compatibility. And I personally believe that a huge part of the reason for Windows success in the marketplace IS that commitment. If we didn't have it, people would have moved onto other platforms long ago.
So when someone starts questioning why ancient stuff exists in Windows, they really need to understand the environment in which those decisions were made. Part of the value of being a young turk is that they challenge the decisions that were made by their elders. But before you decide to challenge an earlier decision, you need to understand the environment in which the decision was made. Sometimes what no longer makes sense did at one time.
Btw, before people start claiming that this was somehow "Microsoft's" fault, the original Mac OS had many of the same issues, it was designed to run on a machine with 128K of RAM and didn't even HAVE a hard disk - it only supported a 400k floppy disk. The designers of the Mac OS made many of the same decisions that the Windows designers did (Mac OS was also a cooperative multitasking environment), in addition, the Mac designers went even further and put significant parts of the OS into the system ROMs on the Mac, further blurring the lines between application and system.