If you really want the error to be raised if one of the subclasses try to call the superclass abstract method, then, yes, you should raise it manually. (and then, create an instance of the Exception class to the raise command raise NotImplementedError() even if it works with the class directly)

However, the existing behavior is actually convenient: if your abstractmethod contains just a pass, then you can have any number of sub-classes inheriting your base class, and as long as at least one implements the abstractmethod, it will work. Even if all of them call the super() equivalent method, without checking anything else.

If an error - NotImplementedError or any other, would be called, in a complex hierarchy, making use of mixins, and such, you'd need to check at each time you'd call super if the error was raised, just to skipt it. For the record, checking if super() would hit the class where method is abstract with a conditional is possible, this way:

if not getattr(super().foo, "__isabstractmethod__", False):
     super().foo(...)

Since what do you want if you reach the base of the hierarchy for a method is for it to do nothing, it is far simples if just nothing happens!

I mean, check this:

class A(abc.ABC):
    @abstractmethod
    def validate(self, **kwargs):
        pass

class B(A):
    def validate(self, *, first_arg_for_B, second_arg_for_B=None, **kwargs):
        super().validate(**kwargs)
        # perform validation:
        ...

class C(A)
    def validate(self, *, first_arg_for_C **kwargs):
        super().validate(**kwargs)
        # perform validation:
        ...

class Final(B, C):
    ...

Neither B.validate nor C.validate need to worry about any other class in the hierarchy, just do their thing and pass on. If A.validate would raise, both methods would have to do super().validate(...) inside a try: ...;except ...:pass statement, or inside a weird if block, for the gain of...nothing.

update - I just found this note on the oficial documentation:

Note Unlike Java abstract methods, these abstract methods may have an implementation. This implementation can be called via the super() mechanism from the class that overrides it. This could be useful as an end-point for a super-call in a framework that uses cooperative multiple-inheritance. https://docs.python.org/3/library/abc.html#abc.abstractmethod

I will even return you a personal question, if you can reply in the comments: I understand it is much less relevant in Java where one can't have multiple inheritance, so, even in a big hierarchy, the first subclass to implement the abstract method would usually be well known. But otherwise, in a Java project were one could pick one of various Base concrete classes, and proceed with others in an arbitrary order, since the abstractmethod raises, how is that resolved?