That choice doesn't always make sense.

It is common for a class to use appropriately placed method calls as convenient "hooks" to let subclasses override behaviour. In fact this is a decent design strategy, and I've been known to recommend it.

But these methods are not public. That is, they are not meant to be part of the public API that the class and its subclasses present to the user. Rather it is part of the private API between the class and its subclasses. So they are private (at least to some extent). But they really have to be done as method calls, because the entire point of the method is to be overridden appropriately in subclasses.

What now? Well one choice is to decide to never add such hooks once the module has been written. In fact this is exactly what the open-closed principle tells you to do. However if you maintain an evolving system over time and adhere to that strictly, then you'll find that this encourages developing a maze of classes that is a maintainance problem of its own.

Another strategy is to say that you'll sometimes accept the up front risk and go ahead anyways. (Making design tradeoffs is, after all, the job of the programmer.) This makes particular sense if you have a closed code-base and are willing to grep it to make sure that you won't create a conflict. But even if you don't, it is sometimes still an acceptable cost. Particularly if you have a stated convention that all such methods will start with a particular substring.

In any case it takes coordination between the maintainer of the class and subclass to make this work and continue to work. If you don't feel comfortable with that, then you shouldn't be subclassing.