Link Details

Some serious misconception about Scrum there. You don't work "extra nights and weekends" if you're falling behind. That would make your velocity completely unpredictable. Time and quality should be constant, this leave you with reducing scope or adding resources. Also, If you run out of work there's always more in the backlog.

I would agree with you that is how it should be, and many of the experienced teams end up doing that anyway.

But that isn't the way Scrum is generally practiced. Scrum is practiced as a limited batch system - within a sprint the scope is fixed. People are trained that the sprint plan is a 'commitment' by the team and they are expected to keep up the commitment (unless something really unexpected happens).

The way you said, you dont need a sprint plan at all. You just keep working off the top of the backlog and whatever gets done is done - which is exactly what is done in kanban.

I can only agree that Scrum gets abused, a lot. It's often implemented improperly where some rules are ignored. You can't blame Scrum for it though, the same people will screw up any agile process, including Kanban.
You're also missing one important thing about Scrum, it gives predictability. With constant velocity and good estimates, you can very reliably predict where your project is going. You can see possible deadlines, or whether your goal is even achievable within your time and budget.
You don't get that with Kanban. Maybe you don't need it, if you're maintaining a project, the scope is fixed, the deadline irrelevant, then why bother with planning, right? It makes perfect sense.
But Scrum and Kanban are not fully interchangeable. Each fits different projects and organisations better. Kanban is not a remedy for poorly implemented Scrum. I don't believe that someone incapable of running Scrum can do it with Kanban.

Well, scrum getting abused is a different matter altogether, and like you said it happens in every process.

However, the commitment oriented sprint plan is the original scrum, and its the way people are trained in CSM courses. If you tell a beginner who has completed a CSM course (at least those I've talked to) to take items from the backlog when you finish early (or drop items when it looks like you cant make it), be prepared to be told that you are abusing scrum ;-) because it is made very explicit that the scope cannot be changed mid-sprint.

I've never been to any of those courses but that makes no sense to me. The whole point of plotting a sprint burndown is to know in advance how you're doing so you can take action. This often means changing the scope if you overestimated, so you can prioritise and focus on what's achievable. Why bother doing that if you sit on this information and do nothing? Does that sound like agile to you? :)
I think it's fairly common though, waterfall, scrum or kanban... whatever. Some people think that, just because you estimated something you can complete it in exactly that amount of time, even if it's not physically possible. They don't understand what "estimates" are.