Abusing the unit test philosophy

Indeed, but isn't that going into the integration tests scope? :)

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.