Why Events Are a Bad Idea (for high-concurrency servers) (2003) [pdf]

What modern server is this describing? "a number of threads ... which poll message queues..."

and what is this describing? "...a completely independent thread for every event."

"Languages based around message passing are thus the obvious choice for this type of programming." Ruby? Obj-c?

When the paper was written, the jury was still definitely out on good concurrency practices for applications: the computing world(apart from mainframes, which of course had learned every lesson 30 years earlier, but nobody paid much attention to) had only relatively recently exited the era where one might ordinarily synchronize your co-processing units at the instruction level, with hand-tuned assembly, just like any other piece of external hardware. Cooperative, event-based programming is familiar to this style. Asynchronous primitives backed by hardware scheduling were the "new kid" for a lot of programmers.

So, like with every technology, there was some exuberance and overuse of a novel formalism which shows up in this paper: "scales to 100,000 threads", it proclaims. Not much later, interest in "green threading" and "lightweight concurrency" grew as a way to get some of the architectural benefits of being asynchronous while mitigating waste from large numbers of threads, and consensus shifted towards mixing the approaches, which seems to have converged on the few-threads, message-queue-per-thread approach.

There were many fast(er than Apache) web servers before nginx, many using various concurrency models, including the one used by nginx.

I agree that they are not contradictory but rather complementary: https://github.com/tinspin/rupy

My web server uses multi-threaded events.

So both!