"It was an issue in Linux for a while, but isn't in recent kernels" is not really sufficient grounds for acting like it's not an issue.
A language designer or library developer, especially, generally can't assert that their code will only run on the most robust, modern, popular systems currently available. They need to work defensively, anticipating the issues that they may plausibly encounter -- especially where those issues will not be apparent to less expert application developers.
And those less expert application developers are in an even worse position, because many barely even know what they're doing in the first place, making all kinds of foolish decisions while they paste together their docker script and relying on inexpert devops/sre people (or end users!) who make their own choices about what things are running on.
It's encouraging to learn that there are now established, widespread, inexhaustibly secure RNG's out there. But it remains irrelevant to a discussion of what developers need to keep themselves mindful of because there remain many implementations in the wild that don't behave like that and most developers aren't in a position to guarantee which their code will encounter.
No, there's really no space for wriggling here. You use getrandom() or, in the worst case, /dev/urandom, and this kernel nit goes away. It was never the case that the LRNG was "exhaustible"; there was only a broken interface to it.
Personally, I forgot that Linux only fixed /dev/random in 2020 in kernel 5.6. That's not that long ago in terms of enterprise / LTS kernels. I'm sure this has been a surprising pain point for end-users for a long time, and perhaps still is in some environments.
Right. But the context here is whether languages can make the (very big) decision to default to a CSPRNG, in which case: you make that decision once, for all your users, and when you do, you don't use "/dev/random".
A language designer or library developer, especially, generally can't assert that their code will only run on the most robust, modern, popular systems currently available. They need to work defensively, anticipating the issues that they may plausibly encounter -- especially where those issues will not be apparent to less expert application developers.
And those less expert application developers are in an even worse position, because many barely even know what they're doing in the first place, making all kinds of foolish decisions while they paste together their docker script and relying on inexpert devops/sre people (or end users!) who make their own choices about what things are running on.
It's encouraging to learn that there are now established, widespread, inexhaustibly secure RNG's out there. But it remains irrelevant to a discussion of what developers need to keep themselves mindful of because there remain many implementations in the wild that don't behave like that and most developers aren't in a position to guarantee which their code will encounter.