My reasoning is that over-riding pre-existing implementations is generally dangerous since understanding how that implementation is connected to other methods is, generally-speaking, hard to do. Leaving these interior classes as purely abstract means that they can only implement common code of all derived classes, usually the common public interface which depends on the purely abstract methods to implement subclass-specific functionality within the framework of a generally common concept.
(Note: in languages without explicitly abstract methods, such as Smalltalk and Objective-C, I assume that these defacto abstract methods are actually either empty or unconditionally throw an exception)
This forces such interactions between superclass and subclass implementations to be explicitly spelled out as part of the abstract methods' APIs.
Obvious concerns of non-private member variables are ignored by this statement as I always assume that no superclass read/write state (as opposed to write-only state which is typically only for logging, etc, and read-only state which is typically just a detail of initialization) can be directly manipulated by any subclass.
There may be cases where this approach seems heavy-weight but I am not sure I can think of cases where it is limited or wrong from a design point of view.
I further wonder if this can be justified by phrasing the idea in terms of prototype-based languages: the interior classes are merely prototype objects and the clones of those objects which specialize in specific kinds of problem are literally their sub-classes. This is probably grasping a little too far but I always try to bring these back to such class-less OO constructs. In short, it is an attempt to limit the impact of the fragile base class problem. Obviously, any language which permits implementation inheritance will experience some degree of this problem but I am trying to find the low-hanging fruit in this suggestion.
Is there anything here or am I missing obvious wrong-ness?