For most teams it's because they don't know any better. Many Scrum implementations start with someone reading the Scrum Guide and begin to follow what's written in there. Mechanistically. It's a process to follow, it's a list of checkboxes to tick. So they follow the process and they tick the boxes thinking they are actually doing Scrum.
Often, the prescribed ways of learning Scrum is through approaches such as Shu Ha Ri which unfortunately start with "obeying the rules". You focus on the tasks (in this case Scrum events and artifacts) without caring too much about the "why". You do so until you eventually "get it", and then you move to the next step and the next. Unfortunately many teams remain stuck in the fist step (the Shu) and keep doing something that they think is the right thing to do.
Because the "why" is lacking, whenever their Scrum implementation meets a roadbump (e.g. traditional project managers, executives, company policies, procedures and regulations, etc), since they don't understand what Scrum is all about, they start to bend its definition. And you end up with ScrumBut.
The thing with approaches such as Shu Ha Ri is that you need to "follow the teachings of one master precisely". This means an expert of some sort that you learn from: a true Scrum Master. And many teams don't have a true Scrum Master, it's just someone inexperienced who fills the role of Scrum Master because you need to tick that box, right? So many teams start by themselves with learning approaches like Shu Ha Ri, so of course they mess it up.
Everyone who does ScrumBut actually thinks they are doing Scrum but (no pun intended) they are not.
There are a lot of other reasons of course but from my personal experience this is the main reason. They use the word Scrum and they think they are doing Scrum, because they don't know any other Scrum implementations than the one they are doing, to compare it to, and see that it's actually ScrumBut.
You might also want to read: