TLDR: Crunch sucks and it always effects the workers at the "bottom" of the company totem pole the worst. I personally believe, after seeing multiple AAA video game projects, that crunch is absolutely almost always a sign of inefficient management and project planning when it occurs and it has a real human cost that can take a lot out of people.
As someone who has crunched on a tangentially related AAA game (that I cannot name) that was delayed twice (the first time for about 8 months, second for another few weeks) I do not think of crunch as something that always has to be a bad thing if it is well managed. The problem is that keeping crunch well managed is notoriously difficult, and there tends to be at least a couple (if not many) inexperienced managers in the chain that really hurt their teams.
In my case, initial "crunch" for my team (QA) on the project was nothing crazy: the managers and leads had to readjust their schedules to cover a newly formed night team, and we moved to a night and day team. This eventually moved to a night, day and skeleton hour team (i.e. almost 24/7 coverage) and even that was mostly fine, since people were not asked to work more than 40 hours a week (aside from some managers who felt obligated to do so, but that's a management style I'll never understand).
Everything seemed fine until about 6 months prior to release, where members of the team started burning out (burn out on a project is normal in QA, it is extremely difficult to play a game you might not like 40 hours a week for extended periods of time, nevermind the fact that some people had been on the project for YEARS at that point) and shrinking because my company had signed a bunch more contracts meaning other projects needed more people.
From that point forward, we were never told we HAD to do overtime, but there was an unsaid expectation both from management (for performance review reasons) and teammates (so they werent stuck doing all the OT) to do at least a little bit of extended hours, and these extended hours initially started with either working an extra 2-3 hours by staying late and then as release drew closer things kept getting added on such as:
1) Saturdays would suddenly open up as a possible workday, starting with half days and eventually becoming full days. A few weeks after that, Sundays were added too.
2) The 2-3 hours once a week I mentioned earlier became 2-3 hours available every day.
At the peak of the overtime craze on our project, I worked 72 hours a week for about a month straight. While I definitely got paid extra and made good money, I was willing to work myself to the bone at the time because I was trying to forget a bad breakup and I also at the time knew it would further my career. It absolutely did too since doing all of that overtime also gave me a good reputation around the office and was worn as a badge of honor, as every time I interviewed for a position to move up at the company from that point forward, the 72 hours every week for a month became an easy answer to the question "Are you dedicated to your projects and willing to see them through?"
After working on and seeing multiple similar projects: "Crunch" can be well managed by adept and highly skilled managers with minimal impact to the team however a large amount of the time it initially starts off as something well planned but all of the wheels fall off the cart at some point.
There is a real human impact to crunch and societal and team pressure are very real things, especially when you are at the lower end of the totem pole and horror stories are spread around the office about people being put on-call (i.e. let go unless needed for emergency work) because they weren't "team players". I was able to leverage the fact that I did a crazy amount of crunch (plus other skills) into a lot of job mobility for myself, but once I got to manage my own teams I quickly learned that my bosses (back when I was low on the totem pole) were under pressure from their bosses to get certain people to crunch because the client (we were outsourced QA) wanted specific, skilled people on the project at all times and did not want to bring in people who did not know the project (since commonly someone new to the project was either brand new and had to be trained or was someone off another project that had to learn the rules and methods of ours).