I guess my recommendation would be... to educate the people involved as to what RPO and RTO actually means and what the impact to the business would be for (for example) the rather miserable 24 hour RPO that they currently seem to have and the fact that there might be no RTO possible unless someone actually verifies that the backups are restorable.

As for Dev and Staging boxes, a lot of people are working their butts off to get code developed and tested.  For that reason, I treat both boxes just like the Production box and have an even tighter RPO and RTO because things happen and people DO accidently delete stuff (data and or objects) in the "heat of battle".  To have lost a two day test setup would be stupid when something is so easy to recover from simply by doing the right thing with backups and testing restores.  And, yes... I restore my two largest databases every night right after the backups complete.  Granted those two databases only take up about 2TB of space but it's essential that we be able to quickly restore if all the other fancy methods that the infrastructure team has (very well) put together.  It also gives me a regular measurement of precisely what the RTO will be in case of such an event.  Even my 2TB telephone system (we're required to keep call recordings forever) has been setup for an otherwise insane "get back in business time" of only 6 minutes and a total RTO of only a few hours (for the remaining 8 years of calls) because of the way we have backups constructed, which is also a strong justification that "one size" DOES NOT fit all.