I find retrospectives demoralizing. I don't want to reherse what we messed up the last 3 weeks every three weeks we allready know that. The constant pressure to "improve" makes you feel bad even though things are going OK.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
I suppose there are good and bad ways to do retrospective. I have seen good ones. I admit I haven't seen many bad ones, mostly because most companies I worked at simply do not have retrospectives at all.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
I think the thing is to go back to the point of the retrospective which is to improve how you're working. You can do that with a regular meeting but that's not the only way to approach things.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.