What are best practices for over-committing resources in a staging environment?
Very good question; I'm interested to see what comes up here.

In terms of cost, obviously each company and team is different.  Ideally, everyone should be resource and cost conscious... but most people really don't seem to penny pinch by heavily monitoring and tuning their workloads (probably as that takes a certain skill level and tool set).  

My Thoughts / Habits:


Unlike most on-prem environments, it is very easy to spawn up dynamic environments in the cloud (if you're automating properly).
So, when cost is prohibitive, you can just spin up full-scale staging environments in order to do load testing and then shut them down.
This will work for most use cases.  Obviously some things do only break when systems are alive a certain period of time under a certain load.   
We usually keep identical but smaller environments in staging.  E.g. linearly scaled down presto clusters/spark clusters, k8s micro-services with less copies, and the like.
We try to keep the actual memory/cpu requests (or config) the same on any tool.  This allows for proper load testing without config changes for anything that scales.


Additional Thought

I'm pretty fond of the DevOps Toolkit book series by Victor Farcic.  If you're using kubernetes, the 2.5 book (https://www.devopstoolkitseries.com/posts/devops-25/) goes into detail on using prometheus and alert manager to detect over-sized or undersized resource requests, among other things.

If you're really into saving resources and testing well simultaneously, it may make most sense to implement and use this in staging and prod.  That way you can tune your alerting and automate your response so you can keep both environments sensibly sized for themselves in a consistent and enforced manner.

I think you'd still want to ensure you could set the staging environment (or another dynamic environment) to the prod settings to load test effectively though.