Cambiaría su pregunta y diría: ¿cuándo un evento basado no es la solución correcta para una aplicación orientada a objetos? Creo que la mayoría de las aplicaciones OO pueden beneficiarse si están diseñadas como productores y consumidores de eventos.
Al final, una "llamada al método" es, de hecho, un mensaje que llega a un objeto y el objeto es responsable de decidir si va a hacer algo con el mensaje y realizar la operación. Esto no está muy claro en lenguajes fuertemente tipados como Java, pero se vuelve más obvio en lenguajes dinámicos como Ruby.
Otro punto interesante del diseño de una aplicación basada en eventos es que, por lo general, los componentes internos deben aislarse y ser coherentes, de lo contrario el código se convierte en un desastre muy, muy rápidamente. Como ejemplo, me gusta mucho el concepto de Arquitectura Hexagonal utilizado por Alistair Cockburn, ya que generalmente este patrón crea una mejor encapsulación y fuerza (en mi opinión) componentes más cohesivos.
Creo (pero probablemente me equivoque) que esto también está relacionado con el concepto de diseño impulsado por dominio de eventos de dominio , en el que las clases de dominio emiten eventos que son capturados por otros objetos, y estos objetos emiten otros eventos (puede ver dónde esto va: D). Lo que me gusta de este patrón es que dice que las interfaces deben modelar roles, no implementaciones.
Lo siento si no tengo mucho sentido, he estado experimentando con estos patrones durante los últimos meses con resultados sorprendentes, pero todavía estoy tratando de entender los conceptos y hasta dónde llegan.