Hey Han! Thanks for the insightful post! I fully agree we should go for out-of-protocol state expiry first and use learnings from that to consider in-protocol state expiry.
In this post you suggest that using in-protocol state expiry leads to better coordination on who holds what state than out-of-protocol state expiry. This point is not completely clear to me in a world where attesters are stateless. Today clients are written primarily for validators and Ethereum assumes a majority of validators are honest and therefore store the state as clients prescribe. Builders, however, are not assumed to be honest and are free to change the client code to a different state expiry rule. Nothing stops them from doing so, even if an in-protocol state expiry rule exists, which I also argue in the Protocol Design view on Statelessness post.
If attesters are stateless, the goal of state expiry is to grow state as much as possible without burdening builders too much with state storage and lookups. My intuition is that we are still quite far from that problem since optimistic solutions like holding frequently used state in memory may be possible as well although I know little about that so would be curious if you agree 
. Since the state expiry rule is designed for builders in the long term, it should be one that they are happy with / incentivized to follow. If the community agrees on a reasonable state expiry rule and state growth rate jointly, I think builders will likely follow the rule since optimizing state storage is probably not worth the R&D costs. Also curious whether that assumption holds!
Finally, FOCIL forces builders to behave honestly by including all txs seen in the mempool. If there is a state expiry rule, we can adjust the FOCIL specs such that it forces builders to behave honeslty according to the state expiry rule. That may mean that users have to provide witnesses for state that the builder is not required to have. However, I think the first principles approach is to think about who holds the state and the state growth rate without considering FOCIL to prevent designing the state “experience” with too much path dependency from FOCIL.