Por que ter um método que retorna um bool / int e tem o objeto real como parâmetro de saída?

Vejo o seguinte padrão de código em todo o lugar na base de código da minha empresa (aplicativo .NET 3.5):

bool Foo(int barID, out Baz bazObject) { 
    try { 
            // do stuff
            bazObject = someResponseObject;

            return true;
    }
    catch (Exception ex) { 
        // log error
        return false;
    }
}

// calling code
BazObject baz = new BazObject();
fooObject.Foo(barID, out baz);

if (baz != null) { 
    // do stuff with baz
}

Estou tentando Fooentender por que você faria isso, em vez de o método simplesmente pegar o ID e retornar um Bazobjeto, em vez de retornar um valor que não é usado e o objeto real ser um parâmetro ref ou output.

Há algum benefício oculto desse estilo de codificação que estou perdendo?

Você costuma usar esse padrão para escrever código como este:

if (Foo(barId, out bazObject))
{
  //DoStuff with bazobject
}

é usado no CLR for TryGetValue na classe de dicionário, por exemplo. Evita redundância, mas os parâmetros out e ref sempre pareciam um pouco confusos para mim

Este é um código antigo de estilo C, antes de haver exceções. O valor de retorno indicava se o método foi bem-sucedido ou não e, se fosse, o parâmetro seria preenchido com o resultado.

No .net, temos exceções para esse fim. Não deve haver razão para seguir esse padrão.

[edit] Obviamente, há implicações de desempenho no tratamento de exceções. Talvez isso tenha algo a ver com isso. No entanto, nesse trecho de código já existe uma exceção. Seria mais limpo deixá-lo subir a pilha até ficar preso em um local mais apropriado.

Dado o trecho de código, parece completamente inútil. Para mim, o padrão de código inicial sugere que nulo para BazObject seria um caso aceitável e o retorno bool é uma medida de determinar um caso de falha com segurança. Se o seguinte código fosse:

// calling code
BazObject baz = new BazObject();
bool result = fooObject.Foo(barID, out baz);

if (result) { 
    // do stuff with baz
    // where baz may be 
    // null without a 
    // thrown exception
}

Isso faria mais sentido para mim fazer dessa maneira. Talvez este seja um método que alguém antes de você estava usando para garantir que o baz estava sendo passado por referência sem entender como os parâmetros do objeto realmente funcionam em C #.

Às vezes, esse padrão é útil quando você, o responsável pela chamada, não deve se importar se o tipo retornado é um tipo de referência ou valor. Se você estiver chamando esse método para recuperar um tipo de valor, esse tipo de valor precisará de um valor inválido estabelecido (por exemplo, double.NaN) ou você precisará de alguma outra maneira de determinar o sucesso.

A idéia é retornar um valor que indique se o processo foi bem-sucedido, permitindo códigos como este:

Baz b;
if (fooObject.foo(id, out b)) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

Se o objeto não puder ser nulo (o que parece correto no seu exemplo), é melhor fazer o seguinte:

Baz b = fooObject.foo(id);
if (b != null) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

Se o objeto puder ser nulo, as exceções são o caminho a seguir:

try {
   Baz b = fooObject.foo(id);
}
catch (BazException e) {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

É um padrão comum usado em C, onde não há exceções. Permite que a função retorne uma condição de erro. Exceções são geralmente uma solução muito mais limpa.