Yes. Ideally you want high coverage of integration tests. If you're going for best quality then sure. The high coverage of unit tests is valuable since we don't want to fail on integration tests. We want to fail on unit tests (easier to trace the failure, faster to run).
Private methods by definition are not an abstraction. Testing them makes absolutely no sense. They are either reachable or they are not.
The one reasonable argument is that it's hard to create a synthetic test that will reach some private methods. That's a valid claim but that's why writing tests is hard. Going directly to the private method is "cheating" and will cause code rot since again, it breaks coverage.
This goes beyond private methods. Say a branch is never reached through a public interface but you test it in your unit tests since you don't know. This aspect is completely hidden from you.
> To convince those who disagree with you, you'll need to make a case for why private methods should in fact be held to a different standard than other levels of encapsulation. I'm open to being persuaded on this point but I can't think of an argument that convinces me.
Encapsulation literally defines this as a core principal. If you don't accept that then you don't accept the most important concept of OOP.
You're thinking about this in the wrong direction. If you want to break encapsulation you need to come up with an argument that's better than: "It's easier for me in this specific case".