This sounds like it might work for PRs for huge features, but not every PR. Coordinating a live demo takes more time than it takes to write entire PRs for most cases. Especially if more than one person needs to see it.
What I dream of implementing at work (once our infrastructure is more fully containerized) is an addition to the CI/CD pipeline where each Pull Request doesn't just kick off tests but also spins up a full staging environment of its own, just waiting for reviewers/designers/PMs a click away. If there were no resource constraints you'd get a separate one for each commit/push so you could compare UX from individual changes.
You don't have to wait until you migrate to containerized deploys. Last year my team started deploying our project to folders named after the branch and setup one apache rule to redirect all *.dev. subdomains to the correct folder. We call them virtual development environments, and they worked really well with our existing QA process.
We're not using the apache cgi plugin for python to resolve dependencies, just packages relative the the application root. I think most languages that can import dependencies can import relative dependencies.
Although my specific setup may not work for everyone, I suspect that there is an equally simple solution for most projects. Containerization is definitely a long-term goal, but it is not prerequisite for automated deploys. The things you have to change to get deploys to work on an existing server will also be useful for containerization.
That's pretty much what we provide at Runnable (Full-stack environments for every branch). Every time you create a branch, we create a new environment for you that anyone on the team can access. Definitely helps to be able to play around with the real app! Every time you push a new commit, we update your environment.