@Twan Thanks, happy to be here!
This would indeed fall under the scope of my research, although I didn’t talk much about mitigating damages after an attack or in case of malicious smart contract administrators.
I would rank all these under better coding practices since they are all enforced on the contract level in the code. They are all also essentially design patterns, which help to mitigate a specific problem. In this case, the problem being the owner of a smart contract having too much power.
I would also say these practices follow the principle of preparing for failure, which indicates that “contract code must be able to respond to bugs gracefully due to the lack of patching schemes” and that “the contract must be able to pause to avoid further financial losses”. These are from a great article, “Smart Contract Security: A Software Lifecycle Perspective”, from 2019. Smart Contract Security: A Software Lifecycle Perspective | IEEE Journals & Magazine | IEEE Xplore.
Other similar examples of design patterns I also mentioned in my thesis and that would fall under better coding practices are pull over push -pattern and commit-reveal -scheme. First one means it is better to let users withdraw instead of contracts sending ETH and the latter one is useful in mitigating front-running in contracts that take submissions against rewards.