Yes, the first concern that came to me when evaluating Davids proposal was also the increase in bandwidth usage. But this already compensated by two factors: more smaller, average sized vaults distributes this load, while strengthening the network. Secondly, archive vaults (the pmid nodes) can evolve to exactly that, archive vaults. We know the majority of the data humanity produces is not accessed again. Firstly the DHT nature of the SAFE network helps reduce this volume of data, but more importantly we need to let the network decide what data has to be (only) archived and what data also has to be fluidly available (with reduced latency);
Remember that the long-standing logic still holds: all data is archived, but if it is archived on a node that is stably online, and never requested again, that data will fall out of the ‘fluid phase’. Until a data chunk has found a node where it can settle on it will indeed keep flowing around.
The flow of data caused by data being requested is not affected by persistent or non-persistant vaults. Neither is the amount of data flow caused by churn events; in fact it is only better spread over the network resources. The network still asks for 4 live copies of the data; the only thing we loose is keeping track of the old-dead copies. We are only removing useless state from the network by introducing the non-persistent vaults, which causes a reduction in overhead to maintain and synchronise.
People also seem to think that if you’d attach a new vault of given size X to the network, it will start sucking a data volume of size X into itself. That is not true. The network only pushes so if it finds space on your newly attached vault it will push new data into it at the rate that the network dictates. Your vault cannot request to store more chunks. It is only ever commanded to store a new chunk, and it will until it is full.