Threads tend to be event driven anyway. If one used, say ObjecTime back in the Olden Days, one could actually configure which FSMs had their own O/S thread and which were shared on a single thread.
This being said, event-driven as a design choice has much to recommend it.
That is event-driven code. A typical accept_connection only returns after receiving a connection event. The I/O code in handle_connection blocks until the event that data can be read/written. The event handling just happens in the OS instead of in userspace with poll/select/etc.
Eh? If you reason that way then all I/O code is evented and that makes the discussion meaningless. Event-styled code doesn't have anything that blocks except the event loop I/O multiplexer and everything returns to the event loop ASAP.
This being said, event-driven as a design choice has much to recommend it.