First, lets clarify what we mean when we say "interface is owned by client". It means that interface is defined by what client of the interface needs and not by what implementer provides. If we were to create a modules of the trio of client, interface and implementer, then first module would be client and interface and second would be implementer, with second module depending on the first one. This goes nicely along Dependency Inversion principles and Interface segregation principles.
That said, I believe, that "interface is owned by client" is the default position in good design. The question should be "Does it make sense for interface to be defined by implementer". For myself, the question is no. There are multiple reasons for that.
First, lets look at GoF design patterns : 
Here, it is quite obvious, that every interface is not defined by the implementer, but by the client. Every pattern allows for arbitrary number and types of implementers. But if client changes, so does the interface. That means the interface and client are more closely conceptually related than interface and implementer.
Second is already mentioned Interface Segregation principle. That says "Client shouldn't depend on interface it doesn't need." This can be paraphrased as "Interface is defined by what client needs." This is quite clear.
Third is the very logic behind interface being defined by implementer. If interface is defined by implementer, it becomes very easy to leak that specific implementer's API. That will make it hard to provide different implementations for the interface. It is quite common sight to see just single implementer for an interface if that interface is defined by that implementer. What is then point in that?
To sum it up : In good, modular and understandable design interfaces (and other abstraction) are first and foremost defined by needs of the clients and are thus part of them. It is a code smell if interface is defined by what implementer provides.
