Why keeping high code coverage constraints in R&D

Why in R&D there is still very high code coverage (>90%) when developing prototypes (no production) that use services that are quite unstable too? Sometimes I have the sensation that keeping this high code coverage is just slowing down the development with no real improvement because the code is changing fast. There is someone that is facing these same issues, if you have explanation why is acceptable to throw away this time with testing code that is very likely to change soon. Or if is maybe worth trying to explain that to the management? Most of the times I find myself just doing dumb tests only to comply to this constraints, I understand that this is not a good signal so I'm asking if and where I'm wrong and which action I could take to improve this. Thank you for your attention.