If you check all implementors of #perform:orSendTo:
you will notice that
 - some always forward the selector to the other object
 - some (TelnetMachine for example) always do it themselves
 - some do the "self respondsTo:" thing
 - some use special-purpose tests.
 - some forward it to 'super' after special-purpose tests.

I think that the comment in Object is quite clear:
  "If I wish to intercept and handle selector myself, do it;
   else send it to otherTarget."
Object per se does *not* wish to handle the selector itself,
so it does just what the comment says it does.

The thing that is missing from the comment is not an accurate
description of what the method *does* but of what the method
is *for* and when you might want to override it.

It is of course part of menu handling.  The only real
sender I can find is in MouseMenuController.  The comment in
Object>>perform:orSendTo: could usefully point to the sender.

Given its use, an implementation using #respondsTo: is arguably
not well written.  Just because a class happens to have inherited
a unary selector doesn't _always_ mean that it intends to have it
called as a menu operation.