As a project manager, I have always promoted frequent retrospectives as a proactive risk management technique. No matter how streamlined the process or plan, there is ALWAYS room for improvement and opportunity to learn and optimize. It doesn't matter if I'm managing a mission critical system cutover with a very structured waterfall methodology, or whether I'm working on a custom product development project with a more agile approach - I encourage retrospectives in order to identify risks early and often and implement frequent smaller course corrections throughout the project. Also, I'm selfish, and I'd prefer to apply the benefits of lessons learned during the current project, rather than wait until the end of the project or phase, when typically I find teams only remember the last few weeks of testing and any launch/stabilization issues, and forget the details from the earlier discovery and planning and documentation heavy phases.
Anyone that has been on one of my project teams knows that I end almost every meeting with the question "are there any other risks or issues we have not discussed today and need to be added to our project log?" As a project manager, I try my best to make a safe space for teams to bring forward risks, but it is a constant battle, especially with new teams and team members that are not as comfortable speaking out during larger meetings with more forceful teammates. If a team is not comfortably bringing up risks early and often, and collaborating on mitigation strategies together, the project is much more likely to encounter issues that pose significant risk to project success, and require more substantial change orders.
I love the idea of pre-mortems because it combines the concepts of both retrospectives as well as a team building opportunity for working together on risk identification and mitigation strategy planning. Instead of just drawing from historical records of retrospectives (if they even exist and are accessible), it invites the team to share their personal lessons learned from their individual experiences as well as their worries/concerns for the current project in a "safe" environment where everyone is sharing at the same time. It also provides a much broader risk pool to start planning from early on vs the battle I often face in dragging the risks out of my teams prior to the point of almost being blocked/becoming an issue.
As children we learn how to knock down towers before we learn to build them. Maybe if we encourage our project teams to knock down, poke holes, and destroy our plans ahead of time, we could start from a much stronger foundation for our projects.