We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like
good meetings that result in actionable decisions.
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
(Not everything fits in two week blocks either)