The most fundamental thing concerning stuff like "best practices" is that you should know what you're doing. If you aren't sure, stick to the "best practice". If you are sure that you fully understand the reason for one of these "best practices" and the consequences, you can vary depending on how you like or the situation requires.
Take GOTOs: The reason for them being banned is that wild GOTOs can make programs difficult to understand and get into an undefined state easily.
But especially in C/C++ that lack local functions, it is usually accepted to use them in error handling and cleanup code.
Assertions in production code are a question of what you want: Do you need a correct result (say, accounting) or do you need maximum performance (say, 3D games, ...).
For my part (application software, frontend and backend), I've made good experiences with letting them in the code. If the programming language and compiler support that, overflow checking, array range checking and stuff like that should also be enabled, at least during testing. I know cases where checks in production code helped finding errors that occured after years of operation without problems.
Some of my customers have the company standard of even to disable compiler optimisation and leave debug code in, although both causes a huge performance "poenality", because correctness and reproducibility, also possible analysis of core dumps, is more important for them than maximum performance.
In my view, the most important task in software development is the reduction of complexity. In most cases it is OK to accept a performance downgrade if it can improve the reliability and maintainability of software.
A point where not too many compromises should be made is error handling. The very least thing you want to do is check for all relevant errors (e.g. return codes) and give out a message where exactly an error occured and with which parameters, ... This can be a lot of work (some statistics claim that error handling can make up more than 80% of a program), but you save most of the time spent there later during debugging.