The "Random" output from the Object Info node is a generated float value. Since the Hue/Saturation/Value nodes are mapped values, 2 "random" numbers with similar floating point precision will have the same effect.
I.e, if object 1's "Random" value is 1.540263, and object 2's "Random" value is 7.540524
The mapped hue values would be 0.540263, and 0.540263. And thus, you need to duplicate the objects a few times to generate a random enough floating point value (anything right of the decimal place) to get a variation.
However. piping those numbers through a logarithmic function maps those values to the logarithmic scale.
I.e (base 0.5), Log(1.540263) = -0.62317671222 and Log(7.540524) = -2.9146647816
And the corresponding mapped Hue values are 0.62 and 0.914, Which results in a substantially difference hue value.
Thank you rrupsis ,but you are unfortunately wrong.
There is absolutely no advantage in using the logarithm of the Random Values.
First of all, the Random Values are already in the 0 to 1 range, so your numbers won't appear like that.
I did some testing to see why the Logarithm gives a better result than the unmodified Random Value, and it seems to me that that is pure luck. The only advantage is, that you can change the Base and thus have more control over the result. It is a bit expensive, though, it might be better to use a White Noise Texture as in the Screenshot:
The image shows the distribution of the random vaules between 0 and 1, with 500 samples; from top down: pure Random output, random through logarithm and White Noise (set to 4D, so you also have a nice Seed). Neither seems better than the other two. With only a few buildings though, you can (and probably will) have huge differences between the three methods.
By the way, the phenomenon that random vallues are sometimes close together ('clumping effect) is 'well-known' under the name Poisson clumping (amongst other names).
Just in case this wasn't clear enough, Random gives random values and you can't get more random than that. The Logarithm trick basically just changes the seed, not the randomness.
What you actually want is that each new building has a different color and you cannot achieve that with random values; if you flip a coin and want a different result each throw (head tails head tails head tails, etc.), that is no longer random.
The closest, to what you want, that I can think of is a construction like this:
(See image next post, can't add it here)
Neighboring houses always have a different color. Mind you. this only works in a modular workflow like we are using here.
Also note that buildings that are 4m apart (Y-Axis) are close together in color (because 4 is 'close' to 4.28571). With 0.7, it works best with houses that are 6m apart (or 5m, or...)
VERY interesting solution 
spikeyxxx.
Note to self: Ask Martin for advice next time I'm stumped by math in a project.
