pull down to refresh

Basically, the problem is entropy.
The problem with libbitcoin wasn't an inability to source sufficient entropy. It was an incorrect choice to use 32 bits of entropy, instead of 128+. (Or a meta problem - creating a seed generation function which apparently people weren't supposed to use (?!) but they did).
Generally hardware wallets are better at coming up with random numbers because their code is harder to compromise, or they might use some random input like the voltage to generate the seed.
Hardware wallets, being very small, contained devices, have much less access to entropy than a PC. This does make seed generation a slightly trickier problem for them. But, true, good point about code being harder to compromise.
To be honest, needing a 16-sided die is stupid. You can just use a D8 and roll it twice. Or even use a D20 and if you get a 17 you can count it as a 1, and so on.
Two rolls of D8 is not the same as 1 roll of D16. The probability distribution of the former is not uniform. Even more, one outcome from D16 - "1" - is not even possible.
Or even use a D20 and if you get a 17 you can count it as a 1, and so on.
Again you're creating a very non-uniform distribution there.
Does it matter if it's not uniform? I'd say it does, but I'd also agree that slightly uneven distributions usually wouldn't matter that much, for private key/master secret generation. But without detailed analysis I wouldn't trust it.
As a scary example, imagine you sourced your nonces for signatures using a method where the final bit (out of 256!) is always zero. This can be enough to leak your private key, if you sign a fair number of times. That is profoundly unobvious - the nonce still has 255 bits of entropy, which is enormous! -but illustrates the point that if you need randomness and you generate something that has any non-randomness in it (such as a biased distribution), you are in dangerous waters.
reply
"Basically, the problem is entropy. The only thing that computers don’t do well is coming up with random numbers. When you ask a computer to give you a random number, it simply uses some algorithm based on the current time to produce one, essentially a hash of that number."
Yeah, that's how insecure PRNGs work, but there are CSPRNGs (cryptographically secure pseudo random number generators) that are perfectly fine to use for randomness. They typically incorporate some real-world element that's truly unpredictable, like mouse movements or background noise... And the algorithm isn't reversible.
You can think of entropy as the number of possibilities... And entropy technically isn't the problem, it's the insecure/predictable/reversible algorithm.