It's faster (and guaranteed success) to simply scan the entire range, than chasing wild gooses with an axe, under the wrong assumption that you can't find two similar RIPEMD hashes in a limited subinterval, or that hashes are equally distributed. Hashes are designed to be indistinguishable from noise, so you might as well have two private keys next to each other (or not) that end up being the same address, or very similar, just as well as you might have two totally (or not) different public keys ending up as the same address. You can't know.

I'm not saying it can't be done, but do you think you are the first one who tried this? Have you sorted out the actual numbers (the answer to your question) since the answer doesn't need to be an opinion, as it can be easily calculated in advance? Even for #67 you'll quickly run into problems with keeping track of the subranges of the subranges of the subranges of the sub-sub-sub-ranges you've scanned, because every time you add an extra byte to match, you have to split all your ranges in half and go through each of those, since you probably assume the range should be covered uniformly. Here's the problem: the address you search for may be located anywhere, not where you think it may be located.