Suppose you have a Model/View/Controller application with a model that emits, say, ten different types of event. You also have more than one view running, but not all views will need to handle all events. If each distinct concrete view class implements the same view interface, each will have to implement methods that can handle, in total, all ten events, even though any given concrete view class might be interested in only two or three different types of event. In that case, each concrete view is going to have a number of implementations that look like this:
If you add new events with new methods declared for them in the interface, you are going to have to add something like the above to every existing concrete view, whether that view is interested in the event or not. If even one of your concrete views extends a superclass, you can't use an abstract class to get around the need to implement every method in the interface in every concrete view. Seems to me that a default implementation does a nice job of solving this problem.
Another approach I've seen (in "Head First Design
Patterns," among other places) is to define a unique interface for each event type (or for each set of closely related events). Each concrete view then implements only the interfaces for the events it cares about. That can lead to a proliferation of interfaces and potential name-collisions between them.
Might this be a case where a single interface with default methods would be useful to someone writing new code, or is the multiple-interface approach the better choice (or something else)?