The following are my own opinions, and not indicative of any ECC policy.
I think what @ebfull is pointing out is that there is a maintenance cost associated with maintaining the ability of the network to verify spend authority of notes in old pools. That cost is somewhat higher for a cryptocurrency network than it is in other kinds of applications, because security analysis must take into account any potential interactions between newly added features and old, deprecated ones.
If deprecation is never followed by removal, then the cost continues to grow over time. If that cost grows so high that new features cannot reasonably be added to the protocol, then what will probably eventually happen is that a fork of the project will remove the ability to spend from those pools, just so that the technology can move forward. In my opinion, what this discussion is about is explicitly planning for such an event, rather than having it happen in a more uncontrolled and/or damaging fashion.
I think that this is also what @zooko means when he says that it’s up to the community. If a future fork of the Zcash blockchain (regardless of what that fork might be named) delivers better value to a majority of Zcash users in such a way that the dominant fraction of the exchange value Zcash notes follows that fork, there is no guarantee that those coin holders of “legacy” pools left behind by that fork would have any ability to spend their funds (on the new fork). So paper wallets, crypto cabochons, and so forth might lose value. And that’s not something that any entity has control over - it’s a collective decision made by a market.
I interpret the purpose of this discussion to be find a path that minimizes the fragmentation by having a transparent discussion of all these issues ahead of time. Then if at some point such a fork occurs… well, at least it won’t be unexpected?
With respect to the idea of software that allows users to move funds one-way, such software depends upon the network being able to validate that move. So there’s not a straightforward way to reduce the technical debt I mentioned earlier until the network can stop validating those moves.