Now that I am with a real keyboard and screen and have tried to understand the OP, I can actually write up my thoughts on the matter.
There are two aspects to the behavior. Giving preference to the class of the right operand if it is a subclass of the left operand's class is reasonable and explained in the docs.
Only doing this if the right operand actually overrides __rop__ was perhaps meant as an optimization, and I expect that when I introduced that rule I hadn't thought of the kind of classes that use type(self) or self.__class__ to return an instance of the runtime class.
However there's also another thing to consider. Consider a variant of the OP example, where B doesn't override __add__ or __radd__, but now add a different __init__ signature, one that requires completely different arguments. This is entirely legal and done often enough (though perhaps not in numpy circles?) -- constructors are not subject to the Liskov rule. So the call to type(self)(<value>) may crash or have an undesirable result.
But given that A does call type(self)(<value>), all its subclasses have to either have a compatible __init__ or override both __add__ and __radd__.