I think the whole issue is very much mystified - unnecessarily so.
First, please note that Mathias described at one point on the mailing list what he's actually interested in - which is running a minimal graphics setup on modestly weak hardware at 60 fps with a hard requirement that frame duration never ever drops below that limit. Given how loading sometimes peaks and drags frame duration, I can readily see how that set of requirement is CPU limited - however I doubt that this is the normal use case.
The normal use case instead seems to be that a user has a computer a few years old, sees ALS screenshots and wants to have the same and sees low framerate. I'm guessing many users would readily trade 60 fps and minimal graphics into 20-30 fps with good graphics and would not have a hard requirement of frame duration.
In any case, the test for limitation is simple:
* switch ALS off, open the detailed shader quality management, switch all to minimum
-> this changes only shaders, nothing on the C++ side, so if framerate goes up, you've been limited by the GPU performance, if framerate remains low, it's CPU speed
-> other tell-tales for GPU limitation are increased framerate when looking at the sky or in fact any change of framerate with view angle
* if you're GPU limited, i.e. see a strong response of framerate to shader quality, switch higher quality back on, use to ufo to go to 3000 ft and compare the view 90 degrees down to the view towards the horizon
-> this changes the number of vertices in the view frustrum only, it is much lower looking down than towards the horizon - however the number of fragments to be processed for the ground is higher looking down. If you see higher framerate looking down than looking towards the horizon, you're vertex-shader limited, if it goes the other way you're fragment shader limited
-> other tell-tales for vertex shader limitation are strong framerate loss with larger visibility or random vegetation and (at least for ALS) no strong response to shader quality level (for technical reasons, it's much easier to leave stuff out of fragment shaders than vertex shaders)
* if you're CPU limited, the next test would possibly be a Nasal-heavy vs. a Nasal-light scenario
If we'd run these tests as a standard for low performance, we'd immediately have a better feeling for where the bottleneck really is. I think Mathias is really working on his use case, and promising that his work will make FG much faster will likely be a disappointment for all the users who want to run the high quality graphics settings which are GPU limited.