Which part? SSR is for reflections, it doesn’t create splotches at all, if it’s low quality then you’ll see noise in the reflections.
For the indirect lighting it uses samples but to save in speed it uses smoothing to blur them together to get a smoother result without having to use so many samples, when it doesn’t have enough samples it creates splotches because the smoothing doesn’t have enough points to smooth together.
In addition to what darthviper107 said, SSR doesn’t calculate light or lighting projection like reflection captures, GI solutions, and Lightmass do. SSR, in very simple terms, simply renders a modified view of the current primary camera and composites that image data onto any pixels in the current frame that meet the requirements of the post process volumes (By that, I mean every pixel that is rendering material information whose roughness value is within the specified threshold, by default it is 0.8, if I’m not mistaken. Then for each pixel that falls within that threshold, the SSR image is mixed with the existing pixel info and further modified by other material information like normal map detail, roughness, color, etc.
Please, someone correct me if I’m wrong, but I believe that’s the very simple overview of how SSR functions. Which is certainly cheaper than essentially re-rendering the entire scene again like with planar reflections.
So I assume that if SSR did participate in lighting calculation it would lead to whiteout situation, because the SSR would reflect more and more light because it recaptures a new image every frame (or is it based on delta time? I actually have no idea which, but for this explanation it doesn’t really matter.) So it would be like adding continuously adding 1 to a number at a very fast rate. So say you start with 10 and keep adding one, soon enough you reach 100, then 1000, then 10000, and so on.
One follow up question though 
Why is that?
I mean, what are the technical difficulties/caveats of implementing the final merge?
Thank you for the explanation! I appreciate the time to educate me 
Of course! Nothing makes me happier than passing on knowledge!
@Luoshuang and @KVogler So I actually went and did a test to see how significant the building time increase was between using the default INI settings and then bAllowIrradianceCaching set to false and built one of me environments using both settings. Both used the “High” Lightmass preset. (Just because my “Production” settings are heavily modified to produce highest quality but also significantly extended build times.)
For the default INI the build took 4 hours and 17 minutes
The modified INI build took 5 hours 26 minutes.
Of course this was performed on a custom indoor environment without either a directional or skylight present. So significantly less calculation was needed as opposed to a large outdoor landscape. But I plan on testing an 8km^2 landscape tomorrow afternoon and take note of the differences.
But, at least as far as this first test has gone, I honestly feel that changing the setting to “false” is absolutely worth it. The quality improvement is staggering in my opinion, especially if you’re intentionally disabling dynamic shadows for static objects. I’m not currently near my system so I can’t post screenshots yet, but I will in the next few days to show how much visual improvement is gained.
Of course, having a laptop to be able to do work on is favorable when the other is building building lighting for hours.