the risk of this workflow is that PRs will languish for too long, and the work required to rebase them when they're actually needed will cause friction and mistakes. this will often manifest when your software reaches a certain level of maturity and you have established a release model that distinguishes between a release that includes only bugfixes and a release that introduces new features.
you definitely want to get your PRs merged in to _something_ as soon as they are complete, to avoid bitrot. but just because they're complete doesn't mean you want them included in the next release.
> but just because they're complete doesn't mean you want them included in the next release.
That's the crux. Continous Delivery means exactly that. You want to release early, small and often. Trunk-based development and having every PR that is merged to master be deployed to production in a very short timeframe fits that very well. That's very possible with a solid CI/CD pipeline, good tests, and something that can be deployed often like a web app.
If you don't do continuous delivery, trunk-based development might be a less natural fit.
you definitely want to get your PRs merged in to _something_ as soon as they are complete, to avoid bitrot. but just because they're complete doesn't mean you want them included in the next release.