Scheduled Retrospectives are Good

I frequently read people state that scheduled retrospectives are a smell. The argument seems to be that a well working team should talk about issues without needing a scheduled ritual to do so, or that management should be able to notice things that need to be talked about.
Well, for one thing, that sounds to me like saying that a car maintenance schedule is a smell, that it should suffice to just go to a garage when you notice a problem. Of course, a car maintenance visit has exactly the purpose of finding problems that you won't notice in your daily use of the car. The same is true for retrospectives: if you notice a problem, you shouldn't wait for the next retrospective to address it. The purpose of the retrospective is to find out about issues that for some reason you don't notice during your day-to-day work.
Additionally, it often seems to get missed that fixing problems isn't the only (and possibly not even the most important) purpose of a retrospective. It also provides the important opportunity to increase the mutual understanding on what has happened, to paint a more complete picture of the project (by assembling the individual pieces of all participants), to share learnings and generate new insights.
As an aside, holding "retrospectives" is a common practice in other professions, too. The military has "After Action Reviews" or "Lessons Learned", firefighters have "Post-Fire Critiques". These are typically held after a mission is over, to reach closure on it and learn for the next mission. I'd think that the end of an iteration/sprint makes for a good equivalent in software development.
In conclusion, perhaps there are teams out there which "don't need" regularly scheduled retrospectives. I'd say it's wrong to think of those teams who choose to have them as necessarily less advanced, though.