And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments are worth it or not.
Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.
Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.
The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.
Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.