Given that JobInProgressListener has only abstract methods, it'll likely change because of additional/deletion/modification of abstract methods. That will break code anyway. Doug, where do you see JobInProgressListener as an abstract class being more amenable to change that it being an interface? Sure, an observer implementation can share state with the scheduler, but that comes with its own set of work - shared data structures have to be exposed, and hence wrapped in getters/setters or classes.
So, given that the JobInProgressListener abstract class is just a collection of abstract methods, and likely will not contain any default state or behavior, I'm just not seeing how it's better to leave it that way than make it into an interface.