It seemed to me that i810 was fine up until Intel got involved with it. I have an unusual chipset (855GM on a desktop with no LVDS output), and new versions of Intel drivers keep totally failing to work on it in various exciting ways. Before Intel engineers started showing up on xorg bugzilla (i.e. when the module was called 'i810' instead of 'intel'), this happened once in a blue moon and I got responsive, polite fixes reasonably quickly. Now, it happens constantly, and I have to beat the engineers over the heads just to stop them closing a bug with comments which more or less translate to "we can't be bothered, sod off". When bugs do get fixed, it tends to take them a respectable fraction of a year to do it.

Interacting with Intel engineers on xorg bugzilla has sort of made me yearn for the days when GNU/Linux hardware drivers were crappy, desperate efforts slapped together with enormous difficulty without any specifications to work from.

1. Linux desktops get 95% or more of their software from a single, trusted source, and savvy users will not click on random executables that they download. Windows users are forced to run executables they download from web sites without really having a way to verify that the source is trusted. I have to do this all the time on Windows; even though I consider myself reasonably savvy, there's simply no way around third-party software if you want to get your work done. That right there constitutes the largest difference between the two in terms of desktop security IMHO.
2. "Opening an infected file," if that file is a data file opened by an already-installed program, and being compromised, indicates that the already-installed program has a vulnerability. Linux security advisories consider these vulnerabilities serious business (they make up the majority of Linux security patches), and have a centralized mechanism for solving them, neither of which seem to be true on Windows in my experience.
3. Servers, by their nature, process requests from anyone anywhere in the world. There's no need to "trick" anyone into clicking on something to get your foot in the door; you can run any CGI program with any input you like anytime you like. The CGI program has to be vulnerable, just as a user program has to be vulnerable to the "infected data file" that you're putting into it. I think the two are different (not really one more vulnerable than the other; they're just not immediately comparable), but saying, "once you've gotten the exploit onto a consumer PC, they're more readily vulnerable than a server is once you've gotten the exploit there, therefore desktops are easier to attack" is just as one-sided as saying, "it's much easier to get access to a server to exploit it than it is to get the exploit onto a desktop PC, therefore servers are easier to attack."

You do realize that using Linux to host a world-accessible web site based on custom PHP scripts, and using Windows to browse the internet as an end-user, and having them both get broken into is not an apples-to-apples comparison?

If you were using IIS to host a web site with a boatload of custom ASP scripts, and that got broken into, I would not be surprised. If that breakin installed an exploit which invaded your up-to-date-with-security-patches Linux/Firefox machine when you browsed the site from Linux, that would be serious news (and an indication that the two were comparably vulnerable to attack).