Your list is good. DB refresh is common practice and the most efficient. Export/import is a relatively tedious process with more possibility of some type of mismatch. A few things to consider:
- Consult with Developers to make sure you're not stomping over development work in Dev or Stage on its way to Production. Schedule ahead of time to allow your team time to consider/review.
- If you have several site collections in each content database, make sure they match up in dev/stage/prod, otherwise you might lose (or gain) something in your lower tier environments you didn't want. For example, in Dev, contoso1_content may contain site collections for Intranet, HR, and Accounting. In Prod, it's possible that contoso1_content contains only Intranet, and contoso2_content contains HR and Accounting, with Intranet in a different contentDB. Note that it SHOULDN'T be that way, but worth verifying beforehand to reduce confusion and fire drills.
- If you're apply Best Practice with different service accounts/app pool accounts in dev/stage/prod by environment, you'll need to adjust your 'refresher' database to match the 'refreshee's'. Ideally, there shouldn't be many SQL accounts to worry about.
- You may also want to be mindful of exposing PII or other sensitive information in lower environments, as rights in lower environments is often broader than in production. eg: the QA team may have access to certain data in the Staging environment they don't have in Production. QA or etc shouldn't need production PII to verify functionality, so you'll need to communicate with Developers to find out which data is sensitive and shouldn't be exposed in the lower environments, and decide who's responsible for removing it after the refresh.
Otherwise I think you're good.