Why would your code coverage metrics include Hibernate (to speak to the example in the post)?
Your code coverage metrics are only going to cover what you've written, not the included jar files. If you don't cover something in there then there's no way to know if it breaks until the bug crops up in production.
Coverage may not be gospel, but it is a useful and interesting metric. I do see coverage data abused in practice often, though, so I agree with your sentiment.
Generally true, though one component's "public API" is another (higher-level) component's "implementation details." I.e. just because a class has public methods, it might really just be an implementation helper for some other class, and not truly a public API, and unit testing it could cause more future maintenance pain than it's worth. So deciding what the public API really is isn't always easy.
My personal rule of thumb is very similar, though: "Test at the highest level of abstraction possible." If you've got some pretty complicated code that could combinatorially explode if you test higher up the stack, then unit test that code. Otherwise I've stopped testing every method and every class and focused on higher-level components and assemblages of classes wherever possible, since I've found those tests to be the most stable, cause the least maintenance pain, catch the most bugs up-front, and do the best job of catching regressions.
The errors I'm most likely to make are generally ones of assembly (i.e. putting the parts together wrong) rather than small-scale bugs like forgetting a null-check or flipping a > sign (i.e. the parts themselves don't work as designed), so I think it makes sense to optimize for catching those sorts of bugs, which generally will also catch most, but not all, of the small-scale bugs anyway.
Your code coverage metrics are only going to cover what you've written, not the included jar files. If you don't cover something in there then there's no way to know if it breaks until the bug crops up in production.