Well there are 52! ways different possible orderings of a full deck of cards. that's about 225 bits. bitcoin private keys only have 128 bits of security. a little entropy loss is probably not a big deal. but it would need to be quantifiable as to how much.
And yet Ian Coleman's method generates a string of 32*5 + 16*4 + 4*2 = 232 bits if you draw the entire deck once, which is above this upper limit of entropy.
But still, how are you going to convert a string of cards to bits? Are you going to use Ian Coleman's method, which as discussed I don't like. Or do you just write your cards out as a string of 7h9sKdAc and so on and hash it? Some other method? How has your method been analyzed and tested? As I said, it is not a trivial problem.
Well I wouldn't necessarily call them "more secure" just because they contribute more bits. those bits are fixed in a particular order so they are just like a single "object" they can't be rearranged.
I don't think they are actually any more secure, hence why I put "more secure" in quotation marks. But if I can draw 4 cards and up with 8 bits of "entropy" or 20 bits of "entropy" depending on the cards, then that's a problem. If I shuffle a deck randomly, then the top card has a set amount of entropy. That amount of entropy doesn't change when I turn the card over and see what it is.
The better way is to develop a true mapping of the 225 bits of entropy 1-1 into bitcoin private keys. simple as that.
Rounding errors aside, there are 2
31 more private keys than card orders, so by doing this you are excluding 99.99999995% of all possible private keys.