The thought experiment of — what should expectations for /future/ (i.e. post-Sapling) value pools be like? — is a good and worthwhile one. At the same time, destroying UTXOs and z-UTXOs /post-fact/ is not acceptable, and seems close to invalidating Bitcoin’s ECDSA UTXOs after Schnorr activates. (This, of course, is an imperfect comparison as merely 15% (edit: not majority) of shielded ZEC value is locked up in Sprout zUTXOs… yet ~all BTC value is locked up in ECDSA UTXOs.) Zcash users have a strong reliance interest of not having their ZEC savings wiped out, and changing this would damage the credibility of the project.
For some users, say, a two year warning might seem ample but this is infeasible for others who have long or expensive key recovery processes. For example, if one invalidated Sapling pool, it would crush the innovative ZEC Cabochon artwork.
What are the concrete ongoing maintenance tasks for Sprout? I’d definitely support making Sprout deprecated / “if you don’t migrate, you are on your own if someone finds a bug” (like users who have non-standard OP_RIPEMD160, instead of OP_HASH160 UTXOs would be) / you need to download this special software to create Groth16 proofs for Sprout migration, but that’s separate from keeping the mature Sprout Groth16 verification / nullifier check code in zcashd.