What does that practically look like? Every time we have to re-walk we have to reverify the integrity of the metadata.
I mean, that is exactly what we're doing right now anyway (unless something significantly changed in CBFS code since the last time I checked). For every single CBFS file access we start at the root and we walk the chain until we find the file we're trying to load (and all of this are real SPI transfers, it's not cached anywhere). Hashing times are generally insignificant compared to SPI access times IIRC (especially since this should be a raw hash, not an RSA signature like we use in current vboot). Validating the hash means we have to walk the whole CBFS directory rather than stopping at the file when we find it, but since we generally don't really pay attention for CBFS file placement for performance right now that's presumably not a big deal (would only double cost on average).
And there are certainly still ways to improve this with the right caching, and ways to do that in a safe way even if verification is involved, which we could explore if we wanted to. I'm just saying as a baseline that the cost of CBFS walks seems to have never bothered us in the past, so the comparable cost of reverifying metadata probably shouldn't be a major criterion to reject the per-file approach.