Some people have noted that AMD Ryzen CPUs tend to have a stronger preference for higher memory clock speeds, while Intel CPUs don't care so much. I finally found a good explanation for it online, so I thought I'd share it.
Let's start with the obvious reason that isn't actually the culprit. Ryzen benefiting more from higher clock speeds could easily happen if Ryzen needed more memory bandwidth. For example, if it had to do more work because it was performing better, that could burn through more bandwidth. If it had a smaller (or no) L3 cache so that more data accesses had to go off of the chip, that would also use more bandwidth.
But outside of programs that scale well to many CPU cores and thus allow an 8-core Ryzen CPU to handily beat a 4-core Kaby Lake, neither of those are true. And outside of such programs, Ryzen doesn't typically need more memory bandwidth than Kaby Lake. Indeed, it commonly needs less. Often, the bottleneck at lower memory clock speeds isn't the system memory at all.
Rather, it's the infinity fabric. Ryzen has two core complexes with four CPU cores each, as well as 8 MB of L3 cache per core complex. The L3 cache is not unified across the entire chip like it is on Kaby Lake, but separate core complexes have separate L3 caches. Having far more L3 cache capacity and bandwidth offers Ryzen some real advantages over Kaby Lake.
The problem comes when a thread moves from one core complex to the other. Now all of its cached data is in the wrong core complex, and it has to move across the infinity fabric. That has considerably less bandwidth than L2 or L3 caches. And the clock speed of the infinity fabric is set to match the clock speed of the DDR4 memory. Higher clocked memory means more infinity fabric bandwidth, and less of a bottleneck.
This is only a problem when a thread moves from one core complex to the other. Moving from one core within a core complex to a different core within the same core complex does not cause this problem. It does mean that data has to move from one L1 and L2 cache to another, but the bandwidth available for that is massively higher and Intel CPUs have the same problem, anyway.
So long as a thread is active, constantly moving it around from one CPU core to another is a stupid thing for an OS to do. Recent versions of Windows are smart enough not to do this. But what if there are a bunch of threads bouncing back and forth between being active and not being active? Then a thread was active, became inactive so that a different thread was scheduled on its CPU core, and then the first thread gets some more work to do again. Is the OS supposed to make the first thread wait until that core is free? That could mean waiting a long time. It's reasonable to just move it to a different core.
What sort of software might do something like that a lot? What if a program is trying to do something perhaps 60 times per second, and each time it does it, a bunch of threads all go through a cycle of being active for a while, then inactive for a while? That's a pretty bad scenario for Ryzen. But if that thing you're doing is the CPU work to render a frame, I've just described a whole lot of game engines.
I'm not sure just how bad the problem is for Ryzen. But it does explain why Ryzen benefits from higher clocked memory in a lot situations where Kaby Lake doesn't. If Raven Ridge has only four CPU cores, that would likely mean one core complex, and hence complete immunity to this problem. Of course, if you're using the integrated GPU, that's likely to make Raven Ridge need a ton of actual memory bandwidth, so it might well still want higher memory clock speeds.