Honestly it is hard going from no code-coverage to a rule of at least x% of code coverage. Instead of adding a blunt rule I went with something different:

Some years ago I've implemented a check to fail the PRs if the lines touched on that PR don't have code coverage (delta-coverage = 100%). We aligned internally with all the affected developers and went with it. We defined that the rule is that 100% of the code needs to be covered, but it doesn't mean that the rules can't have case-by-case exceptions. Whenever someone needs an exception the teams gets together and approve an exception. Sometimes it is a backlog to write the tests later, or some files that don't need unit tests altogether.

This may have worked for us because we are 5 years into this codebase and it keeps on growing, but for more small projects this may be more hassle than it is worth.

Honestly, after the first 6 months (not easy, not gonna lie) I felt better about the codebase, and I love the confidence of trying things and having unit tests all around. There were times where I submitted a PR and forgot altogether to write tests and this rule caught me.

I recommend it, but as with any software development practice, this is not a one-size-fits-all game.

This removes so much headache in the long run. Often by writing tests you discover something not considered before and that improves the product a lot and its stability. I have some projects that have been online for like 4 years now without reboot. They have very good coverage. I hate going through logs and debugging, and I almost never do it after committing to testing. Things just work.

I think error budgets are an excellent idea for this type of tension.

Release crap that breaks too often? OK, you have taken too much of another team's resources, and will have to release less and/or check your work much more carefully.

Release something that might look low quality to an outsider, but that actually works perfectly well? Fine - no negative consequences if nothing bad happens.

This is fine when errors have clear boundaries or the system is more or less trivial. It's easy to have clearly defined error budgets and assignment of blame. In more complicated systems (e.g. mature companies or complex architectures) the assignment of blame becomes problematic, and that makes the tool (error budgets) less useful.