I can't decide if I buy this or not. On one hand, the site has an interest in making sure things are fixed, and showing details of the initial close reason could help efficiency. On the other, that's not the whole goal/story.
If a post has multiple problems, we want them all to be fixed, not just the one that shows up as the official closure reason. If you go to a hospital complaining of a broken leg, you definitely want to get that set, but you don't necessarily want the doctor to miss a gash on your arm because they were focused exclusively on your leg.
Getting back from the analogy to our actual situation, it might be better to present posts without comment, and let reviewers evaluate them "fresh". After all, what ultimately matters is that a post is of sufficient quality to exist on the site, not the amount of progress it made from its previous state.
We already do a similar thing with the popular community standard of asking editors—especially edit suggestors—to fix all the problems with a post, rather than (for example) indenting a code block but ignoring blatant typos.
In addition to pure post quality, the way we're training/affecting users is worth thinking about. For an author who edits a closed post and then is told it can't be reopened without a whole different set of fixes, there's some chance of learning how to write a post more in line with site standards, but a huge chance of learning to dislike both the indirect process and some perceived cabal of arrogant power users.
After all this, I was going to propose allowing multiple close reasons per post, but it turns out there's an existing, moderately popular proposal to do just that, for largely these reasons. But as noted there, it could introduce other issues.