¿Alguien sabe por qué NextStep / Apple decidió tomar el "método conveniente" de no hacer nada al pasar un mensaje a un objeto Nil, pero el "método Java" de generar una excepción al pasar un objeto instanciado a un selector no válido?

Por ejemplo,

// This does "nothing"
NSObject *object = Nil;
[object thisDoesNothing];

object = [[NSObject alloc] init];
// This causes an NSInvalidArgumentException to be raised
[object thisThrowsAnException];

Entonces, por un lado, tenemos la conveniencia de no tener que verificar Nil (asumiendo que no nos importa mucho el resultado de la llamada al método), pero por otro lado, tenemos que buscar una excepción si nuestro objeto ¿No responde a un método?

Si no estoy seguro de si el objeto responderá, tengo que:

@try {
    [object thisThrowsAnException];
} @catch (NSException *e){
    // do something different with object, since we can't call thisThrowsAnException
}

O,

if([object respondsToSelector:@selector(thisThrowsAnException)]) {
    [object thisThrowsAnException];
}
else {
    // do something different with object, since we can't call thisThrowsAnException
}

(Esta última es probablemente la mejor manera de hacerlo, ya que si el objeto es Nil, el selector NO generará una excepción, por lo tanto, su código podría no comportarse de la manera deseada).

Mi pregunta es: ¿POR QUÉ Apple decidió implementarlo de esta manera?
¿Por qué no hacer que la llamada de selector no reconocida a un objeto instanciado no genere una excepción?
Alternativamente, ¿por qué no hacer que el objeto Nil genere una excepción si intenta llamar a un método?