I think that there is a bit confusion on what exactly PatchGuard is supposed to accomplish. I don't really think that it's an antimalware initiative so much as something to force third party driver vendors that do sleazy things (of which I would absolutely rate AV/security software as #1 in doing badness in kernel land on Windows) to clean up their act a bit. There might be a lil bit of marketting spin to that effect, but I seriously doubt that malware prevention is the real purpose here.
PatchGuard is not out there to stop the "bad guys" from rootkit'ing your box. It is, however, designed to stop the McAfee's of the world from designing, shipping, and supporting products that rely on unsafe hacks on a large scale (at least in my opinion). I would imagine that PatchGuard is in this respect mostly a stopgap designed to make the large scale implementation of kernel patching on released products difficult enough to be not worth it (especially from a support perspective, when your target can change with any hotfix, as it did when PatchGuard v2 was deployed to Windows Server 2003 x64 in a critical update some months ago) until there is sufficient infrastructure in place in the operating system to take advantage of the new hardware support in most shipping processors today to prevent kernel patching after boot.
For all the bad press people give Microsoft, they have some very smart people working for them, and they have no illusions about protecting against malware running with the same privilege set as the kernel. PatchGuard is not about malware, it's about stopping people from releasing software that does things like poke internal structures without proper synchronization, hook system calls without validating usermode-based parameters, and other things that generally destroy the reliability and security of the system as a whole. These same people also know that PatchGuard in its current form is only a road bump (and a defeatable one at that if one is so determined), in the form of obfuscation and the like, to prevent this sort of behavior in kernel drivers. The key is to make the target changable enough that vendors will think twice before trying to support something that attempts to hack around PatchGuard.
That being said, I don't necessarily agree that PatchGuard is the best solution to the problem. There are a number of very interesting things that you could only do by patching the kernel on Windows, but unfortunately, at this point, the number of vendors that use this power "for evil" (read: introducing instability and security holes) seems to be the majority. It will be interesting to see how Microsoft intends to address this in the future, as there are a couple of legitimate products I know of which are negatively impacted by PatchGuard.
BTW, about the operating systems supported by PatchGuard: This includes x64 versions of Windows Server 2003, and x64 versions of Windows Vista. (The x64 version of Windows XP uses the Windows Server 2003 x64 kernel, and thus also has PatchGuard included.) x86 versions of the above operating systems do not have any kind of patch protection mechanisms like PatchGuard.
Oh, and as a quick side note: The more conspiracy-theorist-minded among you might see some interesting parallels with hardware-based kernel patch protection, TPM, kernelmode code signing requirements, and the like. I'll leave it up to you to decide where things are really going with that, though.