Obviously there are some applications for which an event driven architecture is the natural fit. My exclusion of GUIs and asynchronous communications servers (what I should have said when I said web-servers), is a tacit admission of that. But even in these, not all their functionality naturally lends itself to being event driven.

In the case of GUIs, their primary purpose is to display information and allow the user to interact with that display. But teh data has to come from somewhere; or go somewhere; and often has to be manipulated in CPU-intensive ways as a result of the interactions. And if you've ever had your GUI freeze up whilst it renders a print job or recalculates your data or parses gigabytes of data from the wrong file, you'll understand that doing these things in-line with the GUI handling code is not a good idea. Sure, it is possible to break up these processes into iddy-biddy chunks such that you can check if the user wants to use the GUI every 1/10th of a second, but that just complicates everything and slows down the long-running processing even further. Pushing such processing off into a background thread is no-brainer. But most (all?) of the event-driven frameworks preclude such simple and obvious techniques.

Even web-servers occasionally have to upload or download a file, or perform some long-running, server-side processing on behalf of individual clients. It is far easier to spawn a thread (or a process), with a client-dedicated, non-http socket, to handle these things, than it is to try and juggle multiple, concurrent such processing through a single event-loop. If the frameworks would only let you.

IRC clients are an interesting case. In effect, they are both multiple-server clients, and a (peer-2-peer) server. And although an event-driven architecture seems a natural fit, I do wonder (I've never actually written one), if, given their nature, a threads + queue architecture isn't a better fit?

Given that most IRC users will be talking to at most, low-10s of servers and peers; and generally such connections will be relatively long running, neither spawn-times nor memory usage are of any particular concern. One inbound queue to the C/GUI component gathers inbound messages for display. With the CUI acting as the dispatcher, routing user input to the appropriate output socket. Then all you need is a single semaphore per server or peer, to ensure that you don't try to read & write concurrently to the same socket, and the picture is complete. One day I'll have to go through that rite-of-passage, and write one to see how the architecture pans out.

Anyway, I know you know all of this--even if you're not so anti-framework as I am--but it is nice to get counterpoint.