I would change your question and say: when an event based is not the right solution for an object oriented application? I think that most OO applications can benefit if they are designed as event producers and consumers.
In the end, a "method call" is in fact a message arriving at an object and the object is responsible for deciding if it's going do to something with the message and performing the operation. This is not very clear in strongly typed languages such as Java, but it becomes more obvious in dynamic languages such as Ruby.
Another interesting point of designing an application as event based is that usually the internal components have to be properly isolated and coherent, otherwise the code becomes a mess very, very quickly. As an example, I really like the concept of Hexagonal Architecture used by Alistair Cockburn, as usually this pattern creates a better encapsulation and forces (in my view) more cohesive components.
I think (but I'm probably wrong) that this is also related to the Domain Driven Design concept of Domain Events, in which the domain classes emit events that are captured by other objects, and these object emit yet other events (you see where this is going :D). What I like about this pattern is that says that interfaces should model Roles, not implementations.
Sorry if I don't make much sense, I've been experimenting with these patterns for the last few months with amazing results, but I'm still trying to understand the concepts and how far they reach.