In case one is not familiar with the author, they are commonly arguing that inheritance is an antipattern that should not be used in OOP languages. The OP is in that context: private and protected are not useful if you don't have inheritence.
Ideally, at least in python, 'true' inheritance should be used in very specific cases, and most of the time, you should only 'inherit' mixins and interfaces.
In practice? abstract classes all the way down to technical debt hell.
It's not true at all. Even Erlang (very much not an OOP language) has public and private methods, with the default being private.
If you don't have a mechanism to indicate which parts of your software's API are internal implementation details and which parts are intended for use by users of that software, then you're going to have to rely on convention. The problem with convention is that no ten people do it the same way... which increases cognitive load... which is to be avoided in a field that has more than enough little things to keep track of already.
> The problem with convention is that no ten people do it the same way
"Stuff that starts with one underscore is an internal implementation detail, use at your own risk" in Python is as close to a universal convention as you can get.
