"No, the fact that this requires local access pretty much means that fixing the problem is typically a waste of time since anyone with physical access likely doesn't need or is even likely to take advantage of ANY exploit to compromise a system. THAT is why it went unfixed for five years, there are actual zero-day exploits that are much more worth a kernel developers' time to fix, not that Linux has a heavy amount of this."
No, you underestimate the kernel people, they won't decide some flaw is a "waste of time" and not fix it. I've seen bug fixes to error paths in drivers, where the person patching admits they are not certain if that error path is actually EVER triggered (it'd be for some highly irregular situation like a card being physically removed mid-transfer), but they found a bug so they fixed it. Apparently, some distro kernels have had a fix since 2004. There was just some screwup so the patch was not put into the mainline kernel.
As for UNIX code in Linux -- there's absolutely nothing like that in the kernel. However, the GNU utilities, and other utilities, significantly predate the Linux kernel. I got an error a few years ago (well, maybe 10) "Not a teletype", and investigating it found the error was from code put into the utility I was using around 1976. Also, it follows POSIX standards, and a lot of UNIX paradigms that predate Linux, sometimes by decades -- I think it's unlikely that some fundamental design flaw is found after this long (as opposed to a Linux-specific implementation flaw), but I won't say it's impossible. So, certainly there could be vulnerabilities found in a Linux distro that predate the Linux kernel.
As for "Linux versus Windows", the example of the 17-year-old hole in the NT VDM. I would just like to point out, Linux had a similar hole in the VM86 system (used by dosemu to run DOS apps) -- for about a month. Within like a month of the VM86 system being put into the kernel, someone ALREADY found a similar flaw to the one hidden in NT VDM for 17 years, and fixed it. BECAUSE they could see the source and see things were not quite right.
Secondly, see MS08-068. Disclosed in 2000, exploit code out by 2001, patched in 2008. After this exploit was disclosed it took over 7 years to patch. I can't find them right now but I know for a fact there've been several other flaws *disclosed to Microsoft*, that they've taken well over 5 years to fix.
Honestly, though, the biggest problem I've seen with Windows security in general is not the odd exploit (that requires code to execute on the system to exploit), it's the fact that people keep finding so many ways to cause code to execute on the system without the user's permission to begin with.