A stock example from OO courses is a Shape class in an application that makes use of geometric shapes. A Shape class would probably have various useful functions, such as draw(), area(), perimeter(), and so on. The Shape class is made to be extended, as the draw(), area(), and perimeter() functions might be very different depending on what kind of Shape we're talking about. Moreover, there seems to be no point to implementing draw(), area(), and perimeter() functions for a Shape that isn't also a Rectangle or Circle or some other specific Shape; users will work with those things, not with Shapes as such. This means there would seem to be no point to making a Shape object, so we might as well make Shape abstract.
In general, when you've got some number of classes that have common data members and superficially similar behavior, but no common underlying behavior, it's appropriate to create an abstract class and have these classes extend it. By contrast, if the classes don't have common data members, it's appropriate to have them implement a common interface.