As you are here perhaps you could explain then why I am getting such a poor frame rate when I've shown there is nothing wrong with my system
No, I can't - I'm not clairvoyant. Basically you need to figure out the bottleneck yourself by successively disabling an enabling various elements.
I've been testing framerate on three different computers for the last decade - they were all held up by different things. My first computer struggled with the fragment pipeline and so I tended to code to make it lean and do work in the vertex shader, but then newer graphics cards turned out to be not much faster in the vertex pipeline but massively faster in the fragment pipeline, so the whole problem was reversed.
Trees as coded initially by Tim Moore (?) had the cool feature that their opaque interior was written into the depth buffer and only the transparent pixels were all rendered, massively reducing the amount of fragment processing for overlapping trees in forests. Unfortunately doing two passes instead of one turned out to be rather expensive for the Macs, so the overhead from the pass rather than the fragment processing time turned out to be the decisive factor on some computers, so the whole idea of two passes was dropped (which was actually slower for me, but helped James a lot).
So with some experience I can tell you what the bottleneck on my systems is (always takes a bit of time to find out and diagnose) but I sure can't do it remotely.
I'm now guessing, but since FSX is over a decade old and a 32 bit application, I assume it's really not that heavy on the graphics card - neither in terms of GPU memory usage (32bit and memory limit - my GPU alone has twice the memory a 32bit application can handle...) nor in terms of GPU workload. For instance, my understanding of seasons and low sunlight in FSX is that they're using pre-computed texture sets, so the variation you'll see in seasons and sunrises is limited - in FG it's all computed dynamically, so no two sunrises will look the same and seasons form a continuum of how the terrain can look like - but of course computing it runtime costs more on the GPU.
Well, the long story short - you'll have to track down the decisive element that costs you framerate yourself because they're very unlikely to exist in the same way for me - no two computers I've ever owned had precisely the same bottlenecks, so it'd be a miracle if yours does. Unlike a commercial software manufacturer who can afford to buy a range of different architectures and test their software on all of them, FG developers only have access to a limited number of computers - I habitually test three different setups (Linux on two computers, one with nvidia driver, one with nouveau driver, Windows on a third machine) - that's all the testing I can do. If some other architecture has a quirky bottleneck, I can't diagnose or fix it without the person who has the problem doing the detailed diagnostics what precise effect/shader/part of the scenegraph causes the slowdown.