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).

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.

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.

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.