no, you had it right the first time:

The interpreter ID is for distinctness, not randomness/unpredictability. (again, I'm using a counter; totally predictable)

The point is to have each process/thread independently generating a sequence of keys that are then used to write into a shared cache and life will be a lot easier if I can just know up front that each process/thread has its own namespace and they're just not going to be clobbering each other, in spite of the fact that they are all running the exact same code.

... if I have to be checking the cache first in order to make sure there isn't a value already written there at that key I'm about to use, and also having to do some kind of locking to make sure nobody else is slipping in a write to that key between the check and when I do my own write, etc... that's going to massively slows things down, not to mention being much harder to get right.

Where randomness is needed is not for the keys but for the values that are being written, which are indeed supposed to be secret/unpredictable/etc... and in particular it's essential that the values being produced on one thread provide no clue as to what values might be being produced on another thread, and so we again need distinctness in the seeding...