Default access does not render the private access modifier redundant.

Language designers position on that is reflected in official tutorial - [Controlling Access to Members of a Class](http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html) and it's pretty clear (for your convenience, relevant statement in the quote made **bold**):
> ###Tips on Choosing an Access Level:
> 
If other programmers use your class, you want to ensure that errors from misuse cannot happen. Access levels can help you do this.
> 
* Use the most restrictive access level that makes sense for a particular member. **Use private unless you have a good reason not to.**
* Avoid public fields except for constants. (Many of the examples in the tutorial use public fields. This may help to illustrate some points concisely, but is not recommended for production code.) Public fields tend to link you to a particular implementation and limit your flexibility in changing your code.

Your appeal to testability as justification for _completely_ dropping private modifier is wrong, as evidenced eg by the answers in http://programmers.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now
> Of course you can have private methods, and of course you can test them.
> 
Either there is *some* way to get the private method to run, in which case you can test it that way, or there is *no* way to get the private to run, in which case: why the heck are you trying to test it, just delete the damn thing...