So with your way of thinking we end up with a simulator good for the computers that are old or low-end. But without the benefits of computer evolution. Why is this a good approach?
Once you look at the facts, the opposite is currently the case - indeed, FlightGear, with its current default settings, will often segfault for people with old hardware, simply because those defaults don't scale too well, i.e. will use unsupported features. And that has nothing to do with entirely optional features like ALS and/or Rembrandt.
This has much more to do with the monolithic nature of the FlightGear process, and its extremely monolithic initialization process, with the majority of subsystems being added unconditionally, with the defaults often not working too well for much older hardware.
So on the one hand we have people like you complaining that the FG default settings look "archaic" and are simply too basic for modern hardware, while we have other users, who frankly are no longer able to run FG without tons of customizing first.
Ironically, however, scaling up is much easier for people (and typically even exposed via the UI) than doing the opposite, for which you need to be really familiar with FG internals (just look at the minimal startup profile on the wiki).
What people have been contemplating to explore/do for a while is implementing a framework for doing dynamic "feature-scaling", i.e. where a safe subset of FlightGear would be booted (as per the minimal startup profile) and the rest (effects, shaders, ALS or Rembrandt, weather systems, visibility etc) would be dynamically determined after this subset of FG is up and running - e.g. using a PID controller that is hooked up to the corresponding PagedLOD (OSG machinery).
Once you take a look at the wiki, you will find that a number of core developers have been discussing the possibilities of dynamical feature scaling, including people like Stuart, James and Rebecca
But for that to happen, it would first of all make sense to implement the required hooks to expose process internals to the property tree, so that these can be queries, but also adjusted, at run-time.
Thus, testing, benchmarking and profiling really is the first step here:
http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing
The next step would be feature-scaling: http://wiki.flightgear.org/Feature_Scaling
In the long term, this would also improve support for older hardware, but also for mobile platforms:
http://wiki.flightgear.org/FlightGear_and_old_Hardware
http://wiki.flightgear.org/Howto:Optimi ... le_devices
In reality, proper profiling/regression testing may not even entail having a graphics window, to see where the non-GPU related issues are coming from, which is why James has been pursuing a headless mode: http://wiki.flightgear.org/FlightGear_Headless
In other words, people are aware of the real problem here and have several solutions/approaches in mind.
But if you really want to help with that, you should also be prepared to get involved with testing - which doesn't necessarily involve patching/building FG from source, but just donating your own time to run several tests and report back with the results here.