Lauer and Needham are to events and threads what Popek and Goldberg are to virtualization: a distraction. The theoretical equivalence in expressiveness between the two models has very little to do with the practical systems programming reality of implementing them.
This paper also handwaves around the difference between preemptive and cooperative threads, as if to suggest that event-scheduled I/O implementers are naturally opposed to cooperative threading. In fact, I/O loads seem to be a motivating driver for coop thread libraries. In that sense, this paper seems to be an attempt to manufacture a controversy where none exists.
Finally, the notion that cooperatively-schedule concurrent I/O is automatically synchronized only on uniprocessors is true but irrelevant. Anybody that builds a cooperative system that needs to run on multiple processors knows they need to synchronize. The point is that coop systems are explicitly synchronized and have stated that is unshared by default, which eliminates large classes of errors (not just straightforward stuff, but also thread serialization and performance issues).
On top of which, not every "Event based" system isn't threaded.
They specifically provide fork/join as an example of Thread based. Scala 2.8 adds full support for using a fork/join model in Actors, which are... to the observer, event driven (message driven event responders backed by threads). Akka, a Scala framework which pulls in a more complete Actor model, Erlang style supervisors and a bunch of Clojure & STM data concepts (among other features) allows you to tune the underlying dispatch for their Actors. You can easily set it up to use thread pools.
Articles like this are going to cause, more than anything, your less-technical management type to suddenly decide event driven coding is bad for some reason. Without knowing that your code which APPEARS event driven on the outside may be thread driven on the inside...
Latency is impossible to guarantee with both threads and events, so neither is very good from that perspective. They don't talk about dead lock either or thread pool exhaustion. Meaningfully assigning thread priorities is nearly impossible as well. Neither is a good abstraction.
This paper also handwaves around the difference between preemptive and cooperative threads, as if to suggest that event-scheduled I/O implementers are naturally opposed to cooperative threading. In fact, I/O loads seem to be a motivating driver for coop thread libraries. In that sense, this paper seems to be an attempt to manufacture a controversy where none exists.
Finally, the notion that cooperatively-schedule concurrent I/O is automatically synchronized only on uniprocessors is true but irrelevant. Anybody that builds a cooperative system that needs to run on multiple processors knows they need to synchronize. The point is that coop systems are explicitly synchronized and have stated that is unshared by default, which eliminates large classes of errors (not just straightforward stuff, but also thread serialization and performance issues).