I agree, but nobody said or inferred that
That seems like an interesting thing to say, given what you said next.
even if you do have "many eyes" (and the vast majority of projects do not) and even if you assume they are the right ones looking in the right place at the right time you will likely find at least some bugs at some point in time.
First, "I agree, but nobody said or [implied] [otherwise]"; the argument is that many eyes make bugs shallow, not spontaneously and instantaneously evaporate. Second, of course "you" will find some bugs at some point. The whole idea is that people will find bugs at some point, and in fact at some sooner point, because more people are looking.
it's hardly a reliable and practical advantage, more of a shot in the dark
I'd say it's an unreliable but highly fucking practical advantage, actually, because when there's only one target it's more likely you'll hit the guy with a thousand shots in the dark than just one or two.
in this case
In this case, the specific bug found seems by all accounts to be something very difficult to find via code review, especially given the OpenSSL codebase.
given the profile of the project this is an absolute best-case scenario
The fact it is a high profile project seems to be the only positive factor in this case, apart from the bare minimum fact that it is open source. There are many, many problems with this case that make it more difficult for this bug to have been found any earlier than it was. A new feature that passed review by one person on the core team was included, then found and fixed less than three years later. It was found by people outside the core team who only had access to the codebase because it was open source. The guts of OpenSSL are heavily compromised by eons of feature creep, which seems to be common to every major/widespread TLS package on the planet. While the wisdom in secure coding of the core team is open to question, for a number of reasons, the team at least seems to be universally pretty clear on some basic concepts of not relying on magic security-through-obscurity fairy dust. The best case scenario for pretty much every closed source TLS package that competes with it differs from these conditions mostly in one or two ways: they are not open source, so they would not have been backed up by the people who found the bug in OpenSSL; they may use magic security-through-obscurity fairy dust to make their code "secure". On top of that, the public nature of the discovery combined with the necessarily public nature of the project's handling of bug patching ensures that the bug got fixed very damned quickly.
Now . . . not all bugs (even critical security bugs) will be found more quickly just because it's open source. See above where I paraphrased: "nobody said or [implied]" that it's always perfect all the time immediately with zero delays so nobody ever has bugs in their software. The actual, reasonable, rational claim is that it provides enough of a benefit, often enough, to make smart open source development processes a very good idea, especially for security software. I think it's pretty reasonable to say that, given the exact same conditions apart from the things that would necessarily be different just due to the intrinsic nature of open vs. closed development models, the best you could reasonably expect from a closed source project in the same situation is almost exactly what happened -- but, much more realistically, it would have taken longer, because someone would have to have nailed down the particulars of the problem without access to the source code.
. . . so no, I don't agree with your point.
it didn't work effectively enough to stop this from being extremely widely distributed.
This is true for this one specific case. I'm going to assume that is not your actual point, now, because if it is, that's a fucking stupid point. Your point should not be "This one slipped through the cracks, in some ways." If that is really the whole of your point, your "I Am Not A Hypocrite" card just got revoked.