Well, again the problem is that one use case that I think absolutely
needs caching - namely, exporting data to graphs, maps, etc. deployed on
wiki pages - is also the one not implemented yet because we don't have
cache (not only, but one of the things we need) so we've got chicken and
egg problem here :) Of course, we can just choose something now based on
educated guess and change it later if it works badly. That's probably
what we'll do.
Wouldn't those usecases be wrapped in an extension or WMF-controlled JavaScript? In that case, queries could always indicate that use, and they could be cached, for hours if need be. No reason to put everything behind a long cache by default, just because of those controllable cases.
Also, what about creating more independent blazegraph instances? One (or more) could be for wiki extension queries, with long cache; others could be for Labs use (internal network only?), a "general" external-facing server, etc.
If the problem (and it's not even certain we have one) can be mitigated or solved with throwing a few more VMs at it, I'm all for it :-)