Why do you care if others have visibility to the interface to these [non-public]methods [and classes]?
At the risk of another flame war: coding philosophy. Maintenance programmers have to identify the responsible classes in a short time, so javadoc generated documentation should describe the public functions that are designed around what it should do, rather than others that deal with 'how'. As you state, naming conventions can make this distinction clear, but it's my experience that an overloaded brain can't so readily ignore even easily filterable information.
Also, when I design a class, I decide at design stage what behaviours are exposed to the outside world, subclasses or other classes of the package. I'm a strong believer in encapsulation: if a behaviour was not designed and tested as public, exposing it without a rethink and retest of the class is too dangerous. If a programmer thinks a private function could be used as public and the compiler denies this, the hurdle of changing the class source code will encourage a proper examination.
Just because some methods are declared public does not guarantee that they will be called in the correct circumstances (and many times may require a correct sequence).
What's your point? Having all message public doesn't help either.
I want mistakes such as passing a string parameter instead of an integer to be trapped at compile-time, not at system testing.
And what if you are passing parameters to-and-fro in a much more loosely coupled framework
The other flame war: I believe in well defined interfaces and strong typing is part of this. I'm a defensive coder and I want anything that can go wrong caught and shot as soon as possible. To me, a change of type is the result, as well as cause, of a change of design.
As for collections, I don't see your argument. If client code in Java is expecting a member of a collection to be an incorrect type, it will miscast it and an exception will be thrown. In Smalltalk, the client code will pass the member messages it doesn't understand and an exception will be thrown. Smalltalk just makes the code cleaner and more readable. This is good but not enough to convince to ditch Java-style typechecking.