Uhm, why should they remove it ? It's safer that way (if ain't broke, don't fix it).
Also, there's still some machinery around running DOS or Win9x..

I don't know about Windows 9x right now, but DOS and Windows 3.1 do crash if they are forced to run an illegal .exe file :
Just did a quick'n'dirty test - renamed a bitmap file to *.exe and launched it. 😉

That's of course not quite the same as running a PE executable without MZ stub,
but it demonstrates how less both of them do worry about broken executables.

Edit: Btw, Win16 apps could run pefectly fine in long-mode; it's just that the Win3.1 subsystem was made to use V86.
- Remember, Windows 3.x can also run 286 protected mode (64KB segments) so at least socalled "Win 3.0 aware" applications
don't perform segment arithmetic like some DOS programs (or Win1.0 apps) might do.

They had to think what would happen if you run x64 exe on a 32-bit system.
If it didn't have the MZ header, 32-bit Windows would think it is a headerless DOS .com file disguised as .exe.

Trying to execute some random bytes could have disastrous results, especially on Windows 9x (and Windows Me was still on mainstream support when 64-bit Windows XP and Server 2003 were released).

So instead, x86 Windows recognizes this as a proper MZ/PE executable, but for a different CPU architecture and refuses to run it.

The same is true for .NET executables: they also have the MZ header, even if they do not contain any native CPU code besides this header.

OT: can you run programs compiled with modern versions of VC++ on Windows NT 4.0 (and earlier...)? What is likely to be broken in such an environment?

Modern versions of VC++ (VS2012, 2013 and 2015) target Windows Vista by default, but you can also enable XP SP3 support.
It seems likely that VS2017 won't have support for XP. (in pre-release versions it is still there but doesn't work)

[UPDATE: VS2017 supports targeting XP SP3]

The last version that targeted XP RTM and Win2k was VS2008.
I don't know when NT4 was killed off.

There are many things "broken" that make programs not work on earlier systems: mostly in the form of dependencies on new system functions and mechanisms in the C++ runtime (that's hard or extremely hard to fix) but also the minimal system version is written to the EXE header (that's easy to fix).

Note that you can still write C# programs for .NET Framework 2.0, so yes, you can use modern Visual Studio versions to write programs that run on 98/Me/NT4/2k (with .NET Framework 2.0 installed), just not in C++.

I asked about this because when I started messing with NT 4.0 a few years ago I moved some useful tools I had written myself to the NT computers but got strange errors when I tried to run them.

superfury wrote:

After looking at Windows 10's 64-bit WOW64 sys files and my own 64-bit version of UniPCemu(compiled using Visual Studio), I notice that it's still using a simply 32-bit EXE (MZ) header, as well as a complete MS-DOS stub? Why would 64-bit sys/exe files still contain a MS-DOS compatibility stub? Even though x64 Windows cannot run 16-bit executables(due to long long mode) without emulation(which Microsoft has ommitted from Windows x64)?

It's needed for both backwards and forwards-compatibility.
Consider the case that a 64-bit file is introduced to a 32-bit system. The 32-bit system has to know how to file the PE header reliably and determine that the file is executable (or not, in this case).
Then consider the case that a 32-bit file is introduced to a 64-bit system. The 64-bit system shouldn't need two different file parsers to deal with two types of file that are essentially the same structure once the MZ header is discarded.