Let me use an example to better explain the difference between both approaches: there is a central class that controls a number of client classes, this is the basic client server approach. Now, in this example, the server has a number of events that the clients can react to. There is a catch though, the server contains a limited number of clients created by it.

The main difference is that signals expose the event protocol publicly in the side of the server, whereas an interface exposes the protocol in the client side. Sometimes is not usefull to expose the protocol publicly, if you consider exposing the way your library works in two levels of users, one level of developing clients for the server and another level where you access the server as a product or component. Accessing the signals directly from the server is not clear, because you are mixing concepts, mixing client development with component usage.

There is a more theorical difference between both, signals are atomic while listeners/interfaces may not be. This is a very crucial difference when your intend is to implement a protocol, it is clearer to the user of your class to read the interface method's signatures then figuring out which signals belong to a certain protocol. I do not consider signals to be very user oriented but they do fill a niche in GObject programming, in my idea, in a wrong way. Implementing signal handlers in C is easier then implementing an interface, because when you implement an interface you have to create a gobject, which might provide to be cumbersome in some cases because of the extensive boiler plate code necessary to implement an object.

But IMO, GObject (the library) users should be 'enforced' to implement Objects in every application they do, this way one can create a more advanced framework that deals only with Objects, this also helps on proper memory management (because of gobject's ref counting).