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'.
You make a couple of assumptions about maintenance programmers. First, you're assuming that the original designer is more capable of making decisions about what is applicable in the mature phase of a project. Problem with this assumption is that it disregards the very existence of the need for maintenance programming. What is that need? It's one of two things: either the original design needs to be extended or it's that the original design is errant. In either case, the maintenance programmer is trying to get around the original design limitations. It's interesting that the original designer created the problem and is now trying to handcuff others because of the belief that his design decisions should be respected (and enforced).

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
Are you saying that the tools for documenting Java source code are superior to those for documenting Smalltalk? I might remind that some of the best development and documentation tools for Java were originally designed for the Smalltalk environment (a not uncommon complaint is that the Java versions are pale imitations - e.g. Visual Age for Smalltalk is better than Visual Age for Java).

Anyhow, the wieght of your argument seems to be that people are (a) incapable of documenting the interface of a class without a syntax enforced public/private statement; and (b) incapable of reading a comment that a method is designed to be private. As I said, Smalltalk uses groups (actually the proper term is catagories) to document the nature of the interface. This is actually more substantial than the public/private identifier as it identifies the nature of the methods in a much more concise grouping. You may help the maintenance programmers by allowing them to disregard the private methods (something which is done in Smalltalk by putting all these methods in a Private group - and no it's not just a method naming convention). But once they get into the methods, you've provided them no additional help in identifying what the purpose of the methods are (unless they read the fine print - something you think they would ignore if you put in comments about being private).

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.
If a programmer starts calling methods without realizing what the purpose and intent of those methods are, i'd say you got much bigger problems than can be solved by merely hiding a few methods.

Let's say we have the reverse scenario. Let's say you screwed up on the software design. Let's say six months later someone stumbles across a bug in the design. Interesting that you seem to believe that the programmer that has to fix the code should have less capacity than you had in the original 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.
The argument is simple. The act of having to typecast means that you are disabling compile time checking. So any time you deal with external interfaces - be it the interface via the web server in the case cited - or an interface to an external datasource such as a RDBMS - you end up having to typecast a significant amount of assigments/statements.