The problem with this line of thought is that it gives an impression of instability since packages break whenever there is a new release of something they were using a private API of. It also discourages communication in favor of quick work arounds. Well, if you need private functionality, why not start a discussion on the best way to expose it?
My experience coming from the Ruby community which (at the time) did not value contracts and visibility that much is that this leads to a lot of pain down the road, especially as systems grow in complexity. Updating only a small part of the system becomes impossible, because a minimal change breaks many unwarranted things along the way. It usually goes like this: let’s update Elixir! Unfortunately, updating Elixir breaks package X because X used a private API. So we have to update package X too but wait! That breaks Y and Z. And so on and so on.
Also beware of “truths made along the way”. It is very likely a community ends-up accepting that “being able to call privates is a good thing” because this behaviour was there since the beginning and it is impossible to change it now, so the best they can do now is to focus on the pros despite the cons. Note this is not a criticism to Python nor I am implying it is the case here, as I am not that familiar with the Python community, but it is an effect we see in all communities, including Elixir’s.
