I strongly suspect systems and instruments are currently the performance limitation, not rendering, so the Shuttle is one of the few areas in FG that are actually CPU limited.
(Otherwise I fail to see why a high-end GPU doesn't get the job done faster, the cockpit is complex but not that complex).
assuming that all of this is using Richard's MFD framework, it should be pretty easy to call .hide() and .show() respectively on each MFD's top-level root group to determine the impact of rendering/not rendering the instruments, while still updating them - as a matter of fact, using a Canvas event listener, it would even be fairly easy to come up with a custom event handler to easily disable MFD rendering by clicking an instrument twice.
You would not even have to touch any of the shuttle's code, but only add the corresponding event handler to the MFD class to have a nice and simple way to easily toggle rendering on/off for certain displays, so that you can see if any of this has an effect on performance or not - I believe, this shouldn't take more than 20 lines of Nasal code added to the MFD helper class, and you could even make it a development option to keep this disabled by default, it might still be helpful though - especially for non-coders not familiar with Nasal/Canvas internals.
With a bit of C++ glue code, the Canvas system and its elements could also be hooked up to the OSG/FG stats handler.