I've seen a lot of terrible tests over my career and some of the most egregious examples seem to have one thing in common: mocking frameworks. By definition the test code becomes very highly coupled to the implementation details of the code under test. Rather than being a "safety net" to enable fearless refactoring, they become a huge impediment.
I now lean towards only public API testing too, but still monitor test coverage. Sometimes this means I write only integration tests, but I'm fine with that. Test coverage is usually still very high. Tests are more meaningful, and usually simpler. If code can't be hit through the public API, then it's candidate for deletion.
So much of our profession seems to be built on unjustifiable dogma, and I think it's great we're starting to see some thoughtful challenges to this. (The recent pushback against thoughtlessly reaching for microservices as a default option is another good example).
Testing internal details is technical debt.
If your change has not effect on the public API contract... why are you doing it? Think harder...