Another perspective: the developer doing the overriding doesn't in fact have more information; they don't know the future plans of the developer of the class they're overriding, and they don't know about the usage models of other descendants of the class and how they'll affect evolution into the future. The more "power" they use, the more likely they'll be left behind on a version bump.
Implementation inheritance means accepting an extremely tight coupling to the ancestor, and overriding is the main mechanism of coupling. Coupling means correlated changes, and when the developers of the ancestor and descendant are in different organizations, it means versioning risk. This is an argument for very careful selection of methods available for overriding, and strictly limiting the choices of the descendant, funneling them into designed-for usage modes.
Versioning is single biggest reason why C# elected to make methods non-virtual by default, where Java makes them virtual by default. Breaking all the clients of your code because of an implementation design change isn't very desireable, thus limiting the surface area for coupling is usually a good idea.
If ancestors and descendants are in the same repository so upgrades of definition site and use site can be coordinated, or the probability of design change in the ancestor is low, then these concerns are more relaxed. But they're valid in many situations.