@loganj, thanks a lot for your detailed and careful motivation. I totally see your points, but this has been a long debate since M13, and I can’t say I have too much to add to what has been said previously.
We believe that the benefits of having public by default outweigh its drawbacks, including those that you have pointed out.
I admit that using the simple measurements that I quoted in that blog post was a bit of a sloppy move, at least because quantitative studies of software are an extremely complicated business, which I had no real intention of entering. But what’s important here is that such numbers are just a quantitative justification (admittedly, rather superficial) to the experience and understanding that we have developed over time using Kotlin and Java. And I trust the latter a lot more than the former.
As an appendix: much of the reasoning presented above is more true for libraries (true libraries that have their own lifecycle with no coordination with the lifecycles of the using applications) than for application code. Unfortunately, we have one language for these two rather different use cases. Sometimes restrictions relevant for library authors may be hindering for application authors (I mentioned DSLs and primary constructors in the blog post). In such cases our general approach is that adding such restrictions (e.g. requiring explicit “public”) is better done opt-in in the tooling (like lint, inspections, etc) than in the language where it affects both camps.