Might just be to reduce the size of the index.

Not sure if they still do, but they used to map keywords to integer identifiers, instead of using the actual string value (string indices get very big). Page and Brin themselves explain it here[1]. I do the same in my search engine.

Problem is there are a lot of junk identifiers, so there's a point to reducing the scope by eliminating probable noise-keywords that are unlikely to ever be relevant to any search. UUIDs and hashes would probably fall into that scope, since they have a very large namespace that can very easily gunk up the lexicon with words that are never ever going to be relevant. You'd probably want to keep the word identifier 32 bits if you can get away with it, but maybe 64 bits for a global search engine like Google.

[1] http://infolab.stanford.edu/~backrub/google.html (section 4.2.4)

This is as much a stab in the dark as any, but as someone that builds/rebuilds ROM sets pretty often (leading me to do a lot of hash-specific searches) I've noticed that there's a lot of crypto-trading related hashes in the indices they maintain.

I'm assuming what happens is that the hashes for various blockchain transactions have a lot of common sub-strings within that collide with non-crypto stuff, hence why they get offered.

Maybe the folks that manage the search engine were finding that these crawls were adding a lot of useless info and just blanket blocked their inclusion?

The top Comment of [0] of the OP has a likely scenario: malware offers periodically searching for hashes of their malware to see if it's detected on the web, without having to submit it to virus scanning websites (as most online virus scan engines will automatically submit the executable for automated malware analysis).

I also would like to know. My guess is maybe password dumps?