You're completely wrong. According to the OpenBSD devs, on modern BSDs and Linux, /dev/urandom is as good a source of entropy as anything. It's commonly implemented by a good cryptographically secure pseudo-random generator. This code only gets called in cases where /dev/urandom is not available (for example in a chroot jail or when the file descriptor limit is reached).
That was not his point. /dev/urandom on Linux does return low entropy strings when it simply doesn't have any at boot time. /dev/(u)random on BSD actually blocks until it has collected enough entropy to get going, and doesn't block thereafter.
So BSD /dev/urandom is more secure in that it never gives bad random numbers for some baseline badness. He was not factually wrong about that, although he is wrong in stating that that was the reason the OpenBSD developers are dismissing it.
You are correct about BSD /dev/urandom vs Linux /dev/urandom. But since LibreSSL isn't likely to be used at boot time, it doesn't try to work around that issue. Instead, the concern is "what should we do if we can't open /dev/urandom?"
For what it's worth, the "exploit" requires (1) the user deny access to both /dev/urandom and the sysctl interface, (2) multiple levels of forks (a child never has the same PID as its parent, but a grandchild can have the same PID as its grandparent, and (3) the grandparent must exit before the grandchild (PIDs uniquely identify all running processes). It's not something that will happen by accident, even to incredibly careless programmers.
But I do agree with the BSD guys that Linux should have another way to get entropy in this case (note that they have a similar file for OS X for similar reasons). And I hope it's not named CryptGenRandomBytes().
The "unlikely"s and "by accident"s in your comment are correct if and only if you assume too much about the scenario in which LibreSSL is to be deployed. It goes far beyond web servers, you know.
For example, what of routers that have no means of entropy input but interrupt timing? What of Android libraries that just use libcrypto? These systems are usually free to exploit by determined attackers!
LibreSSL/OpenSSL doesn't think "unlikely" and tries to cover as much as possible. The TLS library needs to work as good as possible regardless of the context.
