I have attempted a similar approach before and my understanding goes as follows:

1) While it's easy to mathematically count how many of those values we are filtering out, it's quite hard to filter out those values and only check keys that fall out of the rules you put in place efficiently, the scanning process overall could be faster as essentially you are skipping ECC on a ton of keys but having to perform a check on every single value sequentially to check if it should be filtered out is additional operations, the key space is still too big and the chances you have of finding the correct key for the puzzle are now lower as you are skipping keys

2) Looking at keys from previous puzzles may give a sentiment of "no 3 of the same consecutive hex characters appear often in the solved puzzles" that seems to be true for low bit entropy puzzles but it's meaningless, unless there was bias or a flawed way to randomize these keys when the puzzle was created, any value has the exact same chance of being the correct key even if it looks like 50000000000000000a

I have tried to scan the range and filter out keys that followed specific rules like "no 4 of the same consecutive hex characters (aaaa,bbbb,ffff etc...)" or "no 3+2 consecutive pairs (aaa00, fff22 etc...)" but with limited computing even performing this filtering would still take a huge amount of time, for reference I used an RTX 4090 and a Ryzen 9 9950x3d and it's just not enough for a range this big, it would still take years.

By no means I want to discredit your method, this is just my experience but I encourage you to experiment and who knows maybe you get lucky, but filtering out values in an efficient manner is quite the challenge especially when you want to optimize for parallelization