My interpretation of a sprint is to commit in the sense to start and work until end of sprint without interruption (hence the name, I don't take it as meaning to go as fast as possible). It does not mean doing as many hours of overtime needed to complete. If the ongoing task has not completed then it carries over to the next sprint.

Calling it an "iteration" helps a bit. Getting rid of all Scrum jargon helps more. Accurate estimates are only available in hindsight. Making accurate estimates the goal means making the best product isn't the goal.

Carrying over tasks to the next sprint shouldn't be a big deal, but it's frequently viewed as some sort of team failure that needs to explained to (bad) management. The more levels up in the organization that your progress is reported, the more motivation there is for management to distance themselves from perceived failure.

It is my belief that this whole Agile morass is caused by programmers naively trying to be helpful and allowing themselves to be measured in increasingly insane ways like "points per sprint" and thus treated like mindless cogs in a machine.

There are plenty of shops where I assume that Agile is working well, but that is most likely a function of management having a respectful relationship with the workforce. In that situation, darn near anything could work.

Yeah, usually the continuous improvement part of Agile is completely overlooked and so is the important aspect that it requires not assigning blame for eveything that does not go as planned.

This is also because most teams and organisations are not agile. They have only seized on buzzwords.