There's important metadata about the structure of a project when looking at the last commit of a group of files: do they all change together? They are more tightly coupled to one another if so. If all the files are touched by each commit, then there's an issue with the project's development process or organization of code. I also tend to run into issues frequently that were introduced by the last change to a particular part of the codebase. If I can navigate to the appropriate directory and look at the commit messages for each file, I can often be pointed directly at the commit that caused the problem and the files involved with the change.
Secondly, when developing, I'm already running the latest version or something later, so looking at closed issues contains no useful information whatsoever. I'm looking for two things: 1) What I should work on next, or 2) Is the problem I'm seeing already reported and has any work already been done on it?
Not showing open issues also has the negative UX that people will look to see if their issue already exists in whatever page they land on, and if they don't see it, create a new one. Therefore, defaulting to closed issues has the potential to raise the number of duplicate issues by some amount. Project maintainers don't like this much.
