AMD's used SRAM as a marketing point before, when it launched Vega. The presentation included the claim that Vega has 45MB of SRAM on-die, and we never figured out just where all of it came from. The L1 and L2 caches, vector register files, estimated ROP cache and vertex parameter cache capacities were still far from explaining the amount. There's likely a sea of pipeline buffers, internal registers, and internal processors adding to that total.
Microsoft could be doing what AMD did and counted every possible SRAM macro on the chip.
Vega didn't have 8 CPU cores and their attendant L3s, which would be very large single contributors to the total for the console.
Cerny mentioned it can be more difficult to fill the larger number of CUs with work in a case where there was a lot of small geometry.
There was a presentation from AMD for GDC2018 where one topic of CU count versus SE count arose, and larger GPUs with more CUs per SE would do better with longer-running waves. There's a bottleneck in terms of how quickly the shader engine can launch waves in GCN, one wave every 4 cycles. In a GCN GPU with 16 CUs per SE, that's 64 cycles to get one wave per CU, and GCN needs at least 4 each to populate every SIMD, so 256 cycles before the last SIMD in the SE has a wave launched. Then, there's usually a preference of at least 2-4 wavefronts per SIMD so that there can be latency hiding, so we can see that fill time can take a lot of cycles.
If the workload has a lot of simple or short-lived shaders, SIMDs could have sub-optimal occupancy because those waves may terminate long before the SE gets back to them.
Smaller GPUs would be able to reach peak occupancy faster, and while they lack the sustained grunt of the larger GPUs, they would have fewer resources idling when dealing with short shaders.
There was a shift in hardware distribution from shader engine to shader array in Navi, but not much detail on the reason or what didn't transfer. The pressure would be more acute if for some reason the SE:CU ratio was still important rather than SE:SA.
Since the rasterizers and primitive units migrated to the SA, it would seem like the launch function would move with them, but there are other things AMD didn't distribute to the SAs. Not much attention was paid to this change, or detail given about what had really changed.
Sony would be testing to ensure the drive wouldn't be obviously non-performant, and would check the physical dimensions of the drive and any attached heatsink/fan.
Given how many M.2 SSDs use the same configuration under a random assortment of metal and fans, I would expect some rejects would work fine if their heatsink were removed and the drive could rely on whatever measure the PS5 has for cooling bare drives (if it does). However, I suppose it would be irresponsible for Cerny to comment that gamers could just tear their drives apart before installing.
The Xbox One had thermal failsafe modes where it didn't immediately shut down. If there's an anomalous environmental condition, the console isn't obligated to follow its normal operation guarantees.
https://www.eurogamer.net/articles/2013-08-14-xbox-one-built-to-automatically-tackle-overheating
AMD's TDP is a somewhat opaque measure of heatsink thermal transfer capability, based on a number of inputs that AMD tweaks at its convenience.
If it were truly a measure of heat, then it would also be a measure of power consumption, because physically they are almost completely the same outside of trace conversions to other forms of energy.
