Update stats with hashing was added for LOW domain attributes only starting in ESD #2, but really wasn't very usable until about ESD #4 (we tried using them on a early project with mixed results until ESD #4). Perhaps this is why you noted high domain hashing using a lot of tempdb buffer cache??? I started running a lot of tests in sp100+ & sp110 as HIGH domain hashing was finally added. As far as why sp130+, I would avoid sp12x due to some known issues and sp1## is simply too old. Some reported issues with hash stats in the sp110 & sp120 range - I was never sure of the exact scenarios as I never hit any, however, I do know that after sp130+, reports of issues are minimal. One consideration that I did that may make a difference is that I always ran them without any attempts to use worker processes/consumers, ran in threaded kernel (vs. process). I will also state that I ran the tests with set statistics resource on and a few other traces and compared to normal update stats without hashing - and update stats with hashing almost always used multiple orders of magnitude fewer resources in tempdb and proc cache. Will update stats with hashing use buffers in tempdb cache - absolutely - but far far far far less than normal update stats.
As far as accuracy 'high domain hashing might produce less accurate histograms' was a caution in some of the early descriptions (similar to stats sampling) - but I have never seen anything horribly inaccurate. In fact, I have found larger discrepancies and problems with folks running with the default histogram steps - and certainly sampling is much more prone to inaccurate stats. One has to recognize, of course, that histogram stats are just that - it isn't an index with pointers to every value - but rather a weighting of distribution of values within a range.....that is quickly outdated with the first DML and therefore is only an estimate/approximation of values.
WRT CR 757246 - that is a problem with sp_sysmon and those that continue to rely on it for monitoring. To *REALLY* monitor threaded kernel, you need to use monThread. Values in monEngine as well as sp_sysmon are merely derived values that sometimes are a bit dubiously accurate due to methods used to approximate the real values from monThread. The specific CR cited was noted that sp_sysmon reports *INACCURATE* IO busy values which is unrelated to update stats, but rather due to outstanding IOs - which of course update stats can be an IO stressor so is an easy repro. It was likely fixed in some release - if you are still on ESD #2, you really really need to consider upgrading to sp130+.....it is ~4 years old at this point....and tons of issues identified/fixed.