Yes that’s exactly right.
Yes, very fortunate! 
I tried to convey that when writing “It turns out account abstraction is general enough to allow for “miner data””. Incentivised miner data was hiding in plain sight all along.
To my mind partially stateless clients make a lot of sense. They provide very significant storage sublinearity, potentially enough to remove any practical storage bottleneck. With rent it is likely the top-level of the trie can be stored entirely in RAM, removing the I/O bottleneck. We also want to engineer transactions to be minimally sized, and storing the top-level goes a long way towards reducing the witness sizes for applications with small amounts of storage.
I briefly touched upon “accumulator sharding” with several accumulators to allow for parallelism. In order to unlock that for applications with easily parallelisable storage needs, my instinct would tend towards account storage being limited to a small array of 32 byte strings (instead of just one 32 byte string). We could incentivise the array to be super small simply by having large storage rent.
Having a small configurable storage array also gives more breathing space for application developers to make use of the tradeoff between storage and witness sizes. Imagine the following scenario, where a contract has 1,000,000+ infrequently-read accumulators objects and 100 extra-frequently-read accumulator objects. It would make sense to put those 100 extra-frequently-read objects in a segregated accumulator to benefit from small witnesses.