Thanks, I stand corrected regarding quad data rate. Overall, I think my larger point stands: that your way of describing things is overprecise for most discussion contexts. A lot of people are confused by simple terms like "bandwidth", so when you start pulling out the niceties of "QDR" and "MT/s" and suggest complex formulas they lose the plot.
My version requires three inputs: bandwidth, RAM data rate, and the fact there are 8 bits per byte. That last fact is comparatively well known. RAM data rate is often written right on the chip, so pictures show it even if people don't know how to derive it. Bandwidth is usually a given number, but can be explained further using the very easy formula [number of chips at once] x 32.
I think sticking to that eliminates confusion. And not just for the less technically-minded--it stops things like your repeating the erro of a "1050 GHz" memory clock, and so forth.
Either way, the system can only move 256 bits at a time. If the CPU needs some of that bandwidth, then it can't be used by the GPU. Hence contention, and lowered GPU bandwidth. On PS4, it seems that somehow this process of CPU access lowered GPU bandwidth by more than just what the CPU was taking. This is out of my depth, so I'm not sure either why that is, or whether it might have been fixed for PS5.
Which is ultimately why it can't reach clockspeeds as high.
What you and many others miss is the scenarios Mr. Cerny referred to as being the usual absolute maximum power draw. We're used to thinking of power draw increasing as game complexity and visual ambition rise. This is true. But past a certain point, that very complexity starts to make games inefficient. Parallelization means work dependent on other unfinished work stalls, which is why you see framerates or IQ drop in demanding sections. Counter-intuitively, the very highest power usage is when complex games run simpler loads. The engine has been optimized to shove as much work through as possible, so when the work is simple--like a menu screen--there are no stalls. Every single transistor ends up in use, and power peaks.
It doesn't need to. Even at a lower clockspeed, there's more than enough compute available to render the menu. But in typical thermal design with fixed clocks, you don't have a choice. The temperature a 100% saturated menu causes at 1.9GHz might match what 95% saturated gameplay draws at 2.2GHz. (Illustrative only, not real data.) But this means a cooling system good enough to cover either situation can't support a 2.2GHz fixed clock. Because a 100% saturated GPU at 2.2GHz will produce too much heat, and you can't have the console shutting off to avoid overheating whenever a player brings up the menu.
Here's where Sony's solution comes in. Remember, it adjusts clock based on the activity of the chip, not temperature. So when the chip becomes 100% saturated by a menu screen or the like, clock goes down. Performance also reduces, but it doesn't matter because you're rendering very little. When the user goes back into gameplay, saturation reduces to 95% and the clock can rise back to 2.2GHz. This is how a cooling system that can't handle sustained 2.0GHz can reach 2.2GHz with Sony's variable approach. Note that all this same logic applies to the CPU as well: due to inherent inefficiencies it should be able to sustain at 3.5GHz in game situations, and only drop with simple workloads that won't be affected.
What about when games hit higher than 95% saturation, though? It appears that Sony's profiling tools suggest this is more likely on the GPU than CPU side, so AMD SmartShift then will allow reduction of CPU provisioning to allow 96% on GPU. There's still a limit, though. Mr. Cerny did acknowledge that at some point, there will come a game that hits 97 or 98% efficiency in gameplay, on both CPU and GPU at the same time. Here, the clock must be reduced, and that game will not have 10.3TF of performance.
But it should take some time (years?) for developers to get to grips with the platform such that they deftly avoid bottlenecks to this extent (such as fully using SMT). By that point, they'll also have come up with less intensive methods to accomplish some of the same shading, so the games will still look better than titles from early in the gen, even though the compute resources are slightly less. And the talk emphasized "slightly". Because of power curves, every percentage point you drop the clockspeed you lower power draw by multiple percent.
All this complexity could be eliminated by just putting in a cooling system capable of handling 100% saturation at 2.2GHz. But this must be huge and prohibitively expensive, because neither platform attempted it. Series X has a novel wind-tunnel design, a huge fan, and a heatsink that takes up a lot of the interior volume, and can't reach even 2GHz fixed. (Neither could Sony, by their own account.)