Well, actually, the question seems to be about reducing the number of classes to be maintained, rather than just files in general, but here's my $.02 worth (or Rs0.85, if you prefer).
Reducing classes for the simple sake of reducing classes can be an issue. On the other hand, if there are lots of large, specialized classes, that's an issue too. My experience with the Amiga Exec taught me that if you do a really good job of architectural design, you can not only do more with less, you can do it more efficiently - only about 5 distinct classes comprised the core of the entire Amiga ROM Kernel. In fact, it's the only OS I've ever seen where doubly-linked lists were a fundamental OS service.
This isn't a job that can be done just by getting in and hacking around. You'll need to spend a lot of time mapping out functionality at a high and abstract level. Find commonalities and determine what their core capabilities are. Shift the system components from 1-off implementations to producers and consumers of common services, but walk the fine line between a bloated does-all-things-for-all-people and a minimalistic service that can't do the job. Subclass when necessary, but not gratuitously. Look long and hard at any class whose (generously-commented!) source code comes to more than about 1000 lines.
And, of course, we have one additional trick these days. There's a wealth of third-party classes available to Java programmers. Things like Jakarta Commons. Consider replacing custom system components with library components. While the total app class count may go up, someone else has gone to the trouble of designing them for maximum flexibility and performance, someone else has debugged them and taken responsibility for maintaining them, and someone else has written documentation. In other words, they're someone else's problem.
And, since they're industry standards, new people coming in may have a shorter learning curve, since they may either already know them or at least there's more documentation on using them.
