It's the world's biggest target for malware, it's a monoculture, and it has a security model that tends toward convenience over security
Yes - the "dragnet" attacks tends to go after the most victims. If your attack has a certain chance of succeeding (like a social engineering attack), you'd be stupid to go after the 1% instead of the 90%. Now, in a *targeted* attack where the attacker singled out a specific victim or group of victims - the attacker will go after whatever those targets use.
and was actually bolted on after-the-fact.
Nope. The current strain of Windows was created from scratch with the present security model from the get-go. The security model is based on tokens and it was designed to be extensible from the start. Also from the start, the designers envisioned that a process or even a thread could have a token *different* from the user token - i.e. a process could run with permissions/privileges different from the user.
The Windows security model also goes beyond the naive file system-focused model where only file system-like objects were seen as important to secure. In Windows - from the start - all system objects (files, directories, windows, processes, threads, shared memory regions, mutexes, users, groups etc) are accessed through object-oriented handles. When you open a handle you specify the access you request, where each object type has it's own access types. The security check is performed right there when opening the object - instead of on each syscall. If the access you request is granted, a system object is created with a jump table (think virtual method table) where the functions you requested access are mapped to the actual system functions, and the other functions mapped to "denied". The upshot of this is that even though Windows has a much more advanced security model which could make security checks more involved, it will usually perform better because it does *not* have to check security permissions on each syscall.
Contrast that with Unix/Linux where the security model initially only considered file system objects. There were only 2 levels: regular users and root, and a large number of functions could only be performed by root. When it was realized that other system types might also need security descriptors, the existing file system was "adapted" by "mapping" non-file system objects to become file system-like. Talk about bolted on!
The Unix/Linux security model is also the only one with a deliberate drilled hole: The SUID/setuid. Here you have a too limited model where regular users are unable to perform perfectly reasonable functions, like changing their own passwords. So what do you do? You let them run as the only user that *can* perform the function, and pray that the process somehow prevents them from performing any of the other functions root can do while running they are running as root. This is a blatant violation of the least privilege principle, but it is now deeply engraved in all Unix systems. Needless to say that this is the most common path for pwning Unix/Linux systems, going all the way back.
The Unix/Linux model was so bad that NSA had to create SELinux (talk about bolted-on!) which creates it's own competing security "context" (a token). When you want to audit the security of a Unix/Linux system you have to consider 3 competing models: 1) The "original" file-system oriented discretionary model with the SUID hole, 2) the sudoers and 3) SELinux/apparmor or whatever has been bolted on the top.
Especially 1) and 2) are worrying, because it is neigh impossible to audit those sufficiently as long as just a single SUID/sudo command is allowed: How do you (as an auditor) know *what* the SUID/sudo command can actually do? Did *you* install the executable, did *you* monitor the compilation from source? What *other* things can ps or even ping do that you don't know about? If I hold up a file or point to a process on your system as asks "who can access this" - you cannot give me a conclusive answer - because the original file system discretionary permissions may not tell the entire story. There may always be a SUID or sudo utility that can access the file *despite* the discretionary access control.
On Windows there are no deliberate holes in the security boundary: If an auditor points to a file or a process or any other object type, you can give a conclusive answer to who can access the object with what access level. It is all in the ACL. If a user is not in that ACL - he cannot access the object.
When considering the desktop it is even worse: Windows actually has meaningful user interface privilege isolation. On Unix/Linux there is *no* isolation. X is about as promiscuous as can be: Any process and snoop on *any* other process keyboard, mouse moves etc. Which means that is an attacker slips by and get to run his code in e.g. Firefox - he can snoop on *anything* you type in *any* window - including terminal where you type sudo or root passwords. Go figure. Windows security model (since Vista) prohibits lower-integrity processes from snooping on higher-integrity processes. Even a normal integrity process cannot snoop on other normal-integrity processes unless a number of conditions are met (it has to declare it's intention in the manifest, it has to be installed in Program Files or System32 etc). And then there's the stupid password caching for sudo...
Unix (Linux) is about as far from a monoculture as you can get while still remaining reasonably compatible between distributions, and it was built with security in mind.
Shellshock, Heartbleed, ...
Not to mention that a common reason to run Linux is LAMP - The P of which is PHP - the swiss cheese monoculture of web programming languages.