I think part of the way to solve this lies in some kind of notification subscription system built with a light caching node that keeps track of what data in the older parts of the tree are being transacted with, perhaps even just holding a live log that keeps track of which items are potentially going to be written to.
The light caching nodes are interface nodes that can be run in smaller storage volumes that keep data synchronised locally relevant to the users going through them, maybe something built with anycast addresses that clients prefer short routes to a closer node, breaking the edge of the network into lower latency hops with usually all relevant data the users are interacting with.
By adding these two features the network knows which branches to keep available and more quickly propagate new data to users interested in it.
Blockchains are linear but they consist of many branched parts, with also even multiple overlapping maps across user accounts and there is an associativity between smart contracts as well.
I probably am not really adding much to the discussion though. This is just applying distributed availability optimisation by using a subscription model based on interface library event loops. By reducing the propagation of data when it is not demanded it frees time to process more data in parallel.