"Should?"
First, staffing is not steady throughout a project. The well-known project-staffing hump is characteristic of most projects. Staffing is the greatest in the middle of the project, and is relatively low at the end. That means that most of the people who should be involved in the retrospective session have moved on to other projects by the time the session is held. Getting their time for something as non-critical as a Retrospective session can be difficult in the face of more pressing issues on their new project.
Second, the project members who are still on the project often have their hands full with post-rollout support, handholding, or problem resolution. So, even they have the same issues with urgent work taking precedence over the non-urgent retrospective session.
Finally, exacerbating the problem is the fact that doing a good retrospective on a project of any reasonable size will take multiple hours. It is not unusual for the Retrospective sessions to be 2-4 hours, or even a full day for a large project! With all of the competing demands for people's time, how can we expect to carve out enough time for the Retrospective workshop?
Every project has natural phases, and we use those phases to break the project into logical chunks. All we need to do is to hold a Retrospective session at the end of each phase. In the Agile methods, these phases are the development iterations (of two to six weeks). But even if you are using a more traditional method with phases that are measured in months, this principle applies well. And it resolves all of the logistical problems that prevent Retrospective sessions from happening.
First, the people who participated in the project during the phase that is just ending are much more likely to be available to participate in the Retrospective session. And since all but the last session will take place in mid-project, the urgent pressures will be less intense. Finally, because the session is looking back over a much shorter period of time, it can be done more quickly, making it easier to schedule. (You can even do it as part of another project meeting!)
The Agile methods (with their short iterations), expect that this looking back will take no more than about a half-hour out of the end-of-iteration meeting. But even if your project phase was three months long, the Retrospective session can probably be completed in an hour or so.
But not every lesson can be applied to the current project. (For example, a lesson about requirements elicitation will not be valuable until the Requirements phase of the next project.) Besides, if we are serious about process improvement, we will want to apply the lessons we learn to any future project. So, we also need a mechanism that allows future projects to benefit as well.
I worked with an organization that solved this problem in a rather elegant way. Early in the project initiation phase (before project planning is done), the project manager searches the Lessons Learned database for prior projects with similar attributes to the new project. The Lessons Learned on those projects become input to the initiation and planning phases for the new one. A simple yet effective way to ensure that the lessons really were learned!
Using these two easy mechanisms, we can convert Lessons Learned from something we should do, into something that we gain real benefit from.