Linux is used in many more contexts than OpenBSD. Moreover, unlike OpenBSD, Linux explicitly promises not to break userspace on new releases. So yeah, the Linux devs are more hesitant about anything that might be a user-visible behavior change.
OpenBSD never removed /dev/random - though they did remove arandom and prandom. But I'm not sure how your response explains the reasons for why they avoided OpenBSD's solution.
OpenBSD behaves like this patch, the article does a good job of describing what it has taken on the Linux side to get to this point and why IMO. In particular it wasn't until recently there was a reliable way to get quick randomness on nearly any machine to avoid blocking for long periods on boot which things had come to expect avoiding in the previous implementation.
The bootloader seeds the kernel from disk, the kernel continually mixes data into the entropy pool from various sources. arc4random(), which provides for kernel/userspace/devices (including /dev/random which is symlinked to urandom), can never block.
Add.: the seed file is unique per installation, and is also updated continously by the system.
Seed files are useful, but not a perfect solution, because they can be snapshotted or cloned in a virtual machine context, or otherwise shared/leaked. Also, they require a device to have writeable memory, which again does not work in all contexts.
I don't think trying to spin this as "OpenBSD solved this years ago" is especially helpful. OpenBSD has made a different set of design tradeoffs than the Linux authors, and both are arguably reasonable designs.
I don't understand what you mean by "trying to spin this", or how that, whatever it means, is not helpful. Helpful towards what? Admittedly I don't know if there has been a successful effort that breaks or otherwise proves OpenBSD's non-blocking solution as insecure, but I'd be glad to read any conclusions if you have any to share - it's why I asked about the reasons behind Linux developers' objection to the solution.
Linux keeps track of "credit" for entrophy pool sources.
Anyone can write to /dev/random - this mixes data into the entrophy pool but it won't be "credited" as securely increasing /proc/sys/kernel/random/entropy_avail . https://www.whonix.org/wiki/Dev/Entropy
If the point of /dev/random is to provide crytographically secure random numbers, then some level of paranoia is needed for determining which sources are "credited" for initializing the pool. https://lwn.net/Articles/760121/
On OpenBSD only root can write to urandom, but anyone can provide entropy through for example disk i/o and keyboard input. I might be wrong, but I suspect the rationale is that if someone has root access to your system, you have plenty more to worry about besides the entropy pool.
OpenBSD's non-blocking design, as you've described it, isn't secure if that file isn't writeable. The security of the design assumes that file is writeable. It may not crash, but instead it "fails open."
I'd rather put it this way: much of the design's security relies on the file being unique, which it is for every installation. The file can only be read and written by the superuser, and if you have superuser access (or access to the host hardware) and can leak or meddle with the file, the host is already entirely compromised.
But what if it wasn't writeable recently but has been in the past? How do you know that the seed data isn't stale and you are starting up the entropy pool in exactly the same state as last time, and the time before that, and ...
In some security contexts this could be a significant concern.
The seed file will go stale if you deny the system to update it. It's the first source for the entropy pool, but it's not the only source. I really have no idea how large effect the random subsystem suffers as a whole if that source is allowed to go stale.
I had heard that the concern was that there are services very early in boot that rely on /dev/urandom never blocking. I’m not sure how true that is, or why it is no longer a concern now.