I strongly agree, albeit from a different perspective. I think "Propose as a Package", where one proposes an individual self-contained package that reviewers can check out and depend on is a superior approach for swift-evolution proposals, in addition to the benefits you highlighted. After acceptance, it can live as an orphaned branch on a "swift-evolution-packages" repo or something similar.
If we really want to, we can reproduce what is proposed here as a meta-package that reexports a rolling window of proposals. That catalogue-like package could be simpler to maintain as well since there's no untangling of code, only reexports to drop.
A fresh self-contained package is easier to propose than a PR against (what could be) a larger body of code. Especially if that body of code is changing (rolling release window) or versioned (availability annotations to drop the decl depending on OS version).
Pitches can evolve over a long period of time without force-rebasing or other PR synchronization. There are so many more options available for collaborative workflows and building upon prior pitches or prototypes.
Reviewers can evaluate just the functionality under consideration, especially if they are already using some preview functionality. No need to swap out their version of a preview package with that from a PR. Independent packages are independently versioned, and they go stale much slower than PRs.
Any dependencies on prior proposals can be modeled with explicit package dependencies, rather than implicit calls in code. Dropping from a meta-package is cleaner because the code never got tangled up in the first place.