IDisposable created within a method and returned

The problem here isn't something that your C# code is explicitly doing, but rather that the generated IL is using multiple instructions to accomplish what looks like one "step" in the C# code.

For example, in the third version (with the try/finally), the return retFoo line actually involves assignment of an additional variable that is generated by the compiler and that you cannot see in your original code. Since this assignment takes place outside the try/finally block, it really does introduce potential for an unhandled exception to leave your disposable Foo instance "orphaned".

Here's a version that will avoid the potential problem (and pass CA2000 screening):

private static IFoo getDefaultFoo()
{
    IFoo result = null;
    try
    {
        if (Baz.canIDoIt())
        {
            result = new Foo();
        }

        return result;
    }
    catch
    {
        if (result != null)
        {
            result.Dispose();
        }

        throw;
    }
}

Obviously, that hampers readability and maintainability quite a bit as compared to the first version, so you'll have to decide whether the likelihood of orphaning and the consequences of not disposing an orphan actually merit the code change, or whether suppression of the CA2000 violation might be preferable in this particular case.

This is a false positive warning. There is no way to return an appropriate instance of IFoo, if IFoo implements IDisposable, without the code analysis tool warning you that you're not disposing of it properly.

The code analysis doesn't analyze your intent or logic, it just tries to warn about common errors. In this case, it "looks like" you're using an IDisposable object and not calling Dispose(). Here, you're doing it by design, as you want your method to return a new instance and its acting as a form of factory method.