So, yes, one thing per file is actually a pretty good idea. Sometimes it's fine to put multiple things into a single file, if there's a lot of small implementations... but for anything even mediumly big, it's good to give it its own file. It helps a lot with navigation.
And yes, I know you can do "go to definition" etc, but if you want to go back and forth between code, separate files is a lot easier. It also makes source control a lot easier, because you can see a file changed and know immediately what it will and will not affect.
Which is not to say that I don't think java got it wrong, it did, it's just that the problem is not with one class per file, but rather that the file heirarchy matters.
I'm not arguing that you never want a separate file, just that having a forced "one class per file" rule just sprays files all over and means you have to jump around more. Java's hierarchy+class=file is just silly; there's nothing stopping people from enforcing that themselves, if they so choose.
Why? Because I have to work with people who don't have resharper installed, and without resharper it's near impossible to find those types without doing a full project search.
Search takes at least a minute. Class view is only useful if you know the namespace. Go To Definition doesn't help if you're looking a definition for an interface and you want the concrete implementation.
Edit: Also, even in C#, the whole "one class per file" is often unwise. So many times I come across projects that have a bunch of bloody files to define interfaces with a handful of members. And then a bunch of implementations that have 2-line implementations. It's sorta ridiculous. I think it's a holdover from Java's idiotic "tie the filesystem directly into the compilation output" approach.