It usually doesn't end very well? Really? Could you share some links of testimonies about that? Because it would be the first time I 'd see someone having lost his funds because he used a physical source of entropy.
On the other hand, we know real cases of entropy generator bugs having led to real losses of funds.
Brainwallets are a good example of why user specified entropy is not a good idea. Note that I did state afterwards that it is sufficiently secure if the user knows exactly what he is doing. Rolling 100 dices at once and having the user choose the sequence of numbers also reduces the entropy (think you can find a thread in the hardware wallet section which I discussed this). The fact that there are so many things that can go wrong, and that most users probably doesn't know how to generate it properly can be quite concerning.
If you can be sure to generate the entropy correctly, and also ensure that you're converting the entropy in a secure manner without any sources of entropy leakage, then go ahead.
Perhaps not "usually" but there is definitely a far higher chance. I apologize for my wrong choice of words.
I consider that poor software implementation, as with how Blockchain.info/.com has always been plagued with. Pushing out an update that includes a faulty RNG is gross incompetence, any changes done to that has to be tested and ensure that the calls are correctly received. That is not their first time with faulty RNG, their signatures were bugged as well. Oh and of course, the fundamental problem is that they were okay with just relying on random.org for entropy, when the internal system fails. For Bitcoin Core, failure to get the CSPRNG from the OS entropy will result in the function failing.
Most codes that requires a high degree of entropy is often hardened with something else, so there is a chance for your survival given a catastrophic failure of several sources, not what Blockchain.info did. Till this day, I still don't understand what is the point of trying to XOR your entropy with data fetched from another site. There is no guarantees that the site is working correctly, the data can be manipulated and you're effectively ONLY relying on securerandom again. So what is the point? If both fails, then you're doomed.
Honestly, I was quite in disbelief when I took a look at their code. Mind you, I was very new to programming (and cryptography) back then but I could identify the possible security risks of implementing something like this.
Moreover how could you be sure there is no bug in the current version of the software you are using to generate your seed?
Read the code. Does it reference the required entropy properly? Those parts that concerns the entropy is often done with loads of scrutiny by far more experienced coders than the average Joe:
https://github.com/bitcoin/bitcoin/pull/14955. Several wallets uses multiple sources of data to fold into the entropy, current time, OS version, etc.
Perhaps you can do better than them, but not everyone understands what they're doing; for example:
Oh, I'll roll 50 dices and I'll get an entropy more random than those derived from /dev/random. Proceeds to roll a very biased dice which perhaps lands mostly on 3 sides out of 6 and ending up with less than 128bits of entropy. That isn't very ideal, at all.