As one of those people who pushes for code coverage, I'd just like to jump in and dump my thoughts, because no tool does what I want and because of that most people don't understand what I'm going for.
The single most important thing is getting code where no consideration was given down to 0%.
This doesn't necessarily mean "all code is covered by tests", though definitely I'd prefer that be a high percent. What it means is all code was either covered by tests, or deemed not worth the time to add a test for and marked as such so the coverage tool ignores it.
Unfortunately, all coverage tools I've ever seen only allow "skip this for coverage", with no nuance. I want at least two reasons for skipping to be built in to the tool, that would be separated in the report:
* Things intentionally not covered because they're simple helpers in the realm of "obviously no bugs", or a small manually-tested API wrapper that works and shouldn't ever change again but that would be a pain or waste of time to write a worthwhile test (significantly reducing the value-to-effort ratio). There are probably other reasons, but those are the two that jump into my mind as the most common in the codebases I've worked with.
* Things that you're not writing a test for because of some other reason, but a test probably could be written for - such as a time crunch while fixing a bug, something complicated you know should have a test but are uncertain about, and so on. This one is measurable technical debt, and ideally should trend towards 0%, but isn't terribly important to do right away - it's a place where a decision was actually made, where losing test coverage is acceptable.
And of course, that leaves code that's covered by no tests and was not intentionally left uncovered. This is what I mean by "no consideration was given" - it's not covered by tests by accident. It's a likely place to find bugs. This is what, IMO, should always be at 0%.
(Quick aside, adding coverage to a legacy codebase would involve marking everything as the second exception. The project functions, but adding all tests immediately is not feasible, so it becomes explicitly marked as technical debt to be reduced over time. All new code then becomes unmarked-by-default where a decision should be made or a test added as the new code is written.)
Having the separate ways to mark uncovered code, and actually using them, is a way to signal to future developers "here be dragons!" when they look at the uncovered and unmarked code.