I suspect that without some C++ level sharing of instanced elements, large numbers of complex (SVG path) symbols + DATA will be an issue.
There's been quite a bit of public and private discussion on various possible caching techniques in the past, some of them are to be found in the wiki - and while I agree that this would be important at some point, the real issue is that keeping the property tree the sole storage mechanism is incredibly powerful and going to be really important, like Tom mentioned various times. I am no longer convinced that we need to get really fancy here... despite counter-examples like the taxiways at KNUQ
In contrast, introducing clever caching schemes in C++ space (e.g. by having an OSG texture for caching and aliasing groups while maintaining a refcount and animating each instance individually), makes some things pretty tricky eventually - for instance, all od_gauge-based instruments have zero understanding of master/slave setups, like those common at FSWeekend or LinuxTag - yet this is an increasingly important use-case for serious or professional users - similarly, support for multiple windows (or even screens) isn't well-integrated with the rest of FlightGear. Proper support for multiple GPUs is another issue.
While most of this applies admittedly also to the Canvas system currently, fixing these, would be fairly straightforward and self-contained (in comparison to touching dozens of places to fix up the 2D panel code, HUDs and C++ instruments etc) - as long as the property tree remains the sole storage (and transport) mechanism, as it applies to the canvas currently - without any fancy form of caching that /might/ break in advanced setups.
Likewise, we've been talking about having a FGCanvas mode built right into the fgfs binary at some point, analogous to how FGPanel works - just as an integrated part of the main code base, while not only supporting 2D panels, but also MFD-style cockpits and even GUI elements.
Realistically, it is only feasible to support such use-cases by having a single common backend that knows how to deal with multiple windows, rendering contexts, GPUs or multiple fgfs instances.
A while ago, I played around with showing canvas instruments in a slaved fgfs instance - and it actually worked pretty well just by using the existing telnet interface, the subscribe command and 20 lines of Nasal to fix up property path index numbers, while the telnet protocol isn't very fast - it was sufficient to show the airport selection map in a slave instance, as a cockpit texture - without any C++ changes. We once had a long discussion about necessary changes to "mount" remote property trees in a local property tree to replicate state - but the experiment showed that even a crude synchronization mechanism like the props protocol works well-enough for a single instrument.
In summary, we really need to make sure that whatever form of caching/optimizations are introduced, that they can work in master/slave setups, and that is automatically the case as long as the property tree is the sole storage and transport mechanism, so if there is some form of cache, it needs to be local and transparent to the property tree - so that slaved instances get their chance to update their local cache, rather than cross-referencing cached items in multiple interlinked instances.
While it may not seem important right now, because most other simulator features are similarly broken or "crippled", the canvas system is the most feasible chance to address these once and for all.
Either way, caching is going to be important, simply because the GUI is going to be 100% canvas at some point - and having multiple instances of a widget seems like one of the most common use-cases, even when not flying.