The piece of my post you quoted there was not a general statement meant to apply to every circumstance. It was specifically talking about the Steam Deck's situation vs. Switch 2's and how they differed with different performance-designs and different efficiences. Never did I suggest that optimizing for a higher frequency couldn't be more efficient, just that Nintendo achieved similar performance at better efficiencies by going for a wide and low-frequency optimum, whereas the Steam Deck pushes past its optimum (which seems to be about 1200Mhz) to achieve better performance but at the cost of halving its efficiency. 

Pegging things to TFLOPs is simply a means of forming a heuristic for dimensional analysis from knowns about Ampere (and the architectures we're comparing it to.) I don't literally think TFLOPs are different on the different architectures, but how the TFLOPs relate to hypothetical rasterization performance units (which is a hidden variable we can only guess through observation) from architecture to architecture can be measured, again to form a heuristic. Likewise, there is a measured data-point that the "sweet-spot" for Ampere GPU's has been roughly 25 GBps of memory bandwidth per TFLOP. It isn't some rule or engineering principle, but a heuristic or "rule of thumb" that may or may not have been used in the design process based on experimentation and measurement, but is useful for fitting things together because that is how Nvidia actually designed the Ampere line. 

To generalize, these exercises are examples of constructing a Fermi Problem and using knowns to make rough, but not totally out-of-place guesses. It's very common in almost every engineering and scientific field when you have many different variables that can be summarized by the relationships between a smaller subset of variables (such as TFLOPs, FPS, Synthetic Benchmark Units, etc in this case.) 

In the conversation that was being had it is already known that we are talking about an Ampere chip (T239) and single-precision, by convention. The missing variables were frequencies and core-counts, with architecture and precision of interest being held constant. 

Node size is important for those things yes, but if we already know the frequency and core-counts (as we essentially now do), it is no longer important for calculating hypothetical single-precision floating point performance. 

You are missing the point.

Just like the current Switch, many developers won't use pure single precision floating point... Ergo using single precision floating point/teraflops is irrelevant when comparing the Switch 2.0 against it's competition.
They will use mixed precision by combining two 16bit operations into a faux-32bit one to be done in a single cycle wherever possible.

This is to conserve battery life and to boost throughput.

This isn't going to happen on the Steamdeck as it relies on PC development/ports.
And it definitely doesn't happen on Playstation 5 and Series X.

I understood your point fine; it just wasn’t really what our conversation was about. We weren’t trying to count every possible operation of each data type that might show up in a typical game workload or account for all of the fine-optimizations that potentially can exist on each platform and that are tailored for that platform. The whole idea was to nail down a broad, top-level, far from precise -- but directionally correct, relationship between single-precision TFLOPs and (measured) effective rasterization performance for each architecture that was being discussed, while leaving out the finer details that can vary—even between GPUs of the same architecture. We got there by aligning measured performance with single-precision throughput on an architecture-by-architecture basis for like chips and noticing that there are directional trends across all GPUs of the same architecture.  

It didn’t have to be single-precision. The decision is arbitrary. We could’ve used half-precision, INT8, TF32, or some weighted combination of them all, based on the distribution of each data type (or operations) used in a typical engine. We just went with single-precision because it’s the most common data-point that can be found in specifications, and it is supported in the feature-set of practically every consumer GPU, and in the most cores. 

And yes, such architecture-level comparisons are imprecise and don't tell the whole picture, but we're not yet at the point where we know the minutia of the Switch 2's hardware and how developers will use it nor does it matter for the broader question that was trying to be resolved. 

numberwang was skeptical that the handheld Switch 2 and Steam Deck were in the same ballpark (and the theoretical performance as well), and these broad comparisons are enough to answer that question. 

FWIW, to help people that want a fast summary of the specs leak:

• CPU: Arm Cortex-A78C
  • 8 cores
  • Unknown L1/L2/L3 cache sizes
• GPU: Nvidia T239 Ampere
  • 1 Graphics Processing Cluster (GPC)
  • 12 Streaming Multiprocessors (SM)
  • 1534 CUDA cores
  • 6 Texture Processing Clusters (TPC)
  • 48 Gen 3 Tensor cores
  • 2 RTX ray-tracing cores
• Bus Width: 128-bit
• RAM: 12 GB LPDDR5

Handheld Mode:

• CPU: 998.4 MHz
• GPU: 561 MHz (~1.72 TFLOPS)
• Memory Frequency: 4266 MHz
• Memory Bandwidth: 68.256 GB/s

Docked Mode:

• CPU: 1100.8 MHz
• GPU: 1007.25 MHz (~3.09 TFLOPS)
• Memory Frequency: 6400 MHz
• Memory Bandwidth: 102.4 GB/s
  
  
  

Basically a PS4 in handheld mode (maybe a little above and 25% less than an XSS I guess). That was basically what i was expecting. For a handheld thats amazing!!