The folks at Integrum, a rails consulting company, produced a short podcast talking about their challenges running single retrospectives with multiple teams.  One of the comments from early in the podcast was when you have many teams in single retrospective, the participants tend to speak in generalities and skip the details of what happened in their team.  Presumably because that information would not be of interest to the other folks not on their teams.

I have facilitated both single team and multi-team retrospectives and my experiences match the ones described by the people at Integrum.  I generally prefer to run single team retrospectives, but there are times when a multi-team retrospectives.  In my experience, these are two reasons why I might want to do multi-team retrospectives:

1. Cross-cutting issues are more important:  when the main issues facing the teams are organizational, run multi-team retrospectives to highlight common obstacles and to look for root causes to these impediments.  In many cases the issues teams want to talk about in a single team retrospective are often times symptoms of these organizational roadblocks.   
2. Resistance from participants: normally when you ask people to reflect on the way they work and look for ways to improve, they are pretty interested to talk.  The times I have seen resistance to retrospectives are when people have participated in forums, e.g. post mortums or after-action reviews, that are so far removed from the events people are discussing, there is no real impact to their work.  Everyone just knows the information from the session will go in some file, be forgotten and never acted upon.  When I encounter this type of resistance, I use the multi-team retrospective as a way to re-build trust and confidence in the retrospective process.