Yeah, you're right, I guess I should've been more clear, using user inputs naively as an RNG is a bad idea, using it as a source of entropy can be useful. I would never entirely rely on it though, noise is a must, all it can really do is speed up true random number generation, and then only if the implementation is right, combining the sources of entropy naively can lead to reduction in security also, to me the risk of that added complexity is not worth the speed up in anything critical, I'd rather not use user inputs at all.

In many cases the next problem would be what to use instead. The alternatives aren’t too great either.

There are great alternatives in principle. The problem is incentives to sabotage alternatives by governments and manufacturers. There are chips that produce real entropy, and processors come with integrated hardware for this purpose. The problem is that you don't know if the hardware is deliberately flawed in some way.

Suggestion: Every device has a built in lava lamp that we process into visual noise... Bring the 70's back in a big way.

Many devices already have hardware sources of randomness built in. The problem is just that they are unverifiable and built by companies that have shown themselves to be untrustworthy.

No, the problem is that the built in sources aren’t funky enough ;)

In all seriousness, though, yes and guaranteeing that the manufacturing process itself can “bake” in the randomness is a super interesting area of research. It’s like 99% of the manufacturing process is an exercise in reducing variability, and then there’s PUFs, where you’re basically trying to maximize variability, but in such a way that you maintain computational precision.

Specifically, PRNGs based on cryptographic algorithms (CSPRNGs) resist loss of existing entropy from having new, low entropy sources appended to the stream.

To my thinking, what is more important is that you don’t fool yourself about the amount of entropy from one source, or among sources. Two entropy sources that are dependent variables may be good separately but not together. Like the timings of keystrokes and network packets may be affected by the scheduler, or the fact that you are typing into a remote editor session which is bouncing ACKs back, or auto saving every time you hit enter or change focus.