Yep. It happens over and over again. You can add Lean and Theory of Constraints to the list.

One of the most egregious abuses of Lean I saw completely failed at one of the things that Lean (in theory) does best: Empowering employees. Instead of letting employees (the ones actually doing the work, in this case in a manufacturing setting) discuss with themselves, engineers, and management the issues and work towards solutions the managers (exclusively, they did not consult the engineers) would observe what happened in the production areas and "Lean" the process (identify waste) then they'd direct the workers on how to do their job better. This was really Scientific Management with a Lean skin. And it failed for all the expected reasons (worker rebellion, in effect).

Theory of Constraints has, though with a reduced emphasis but it's still there, the same idea of empowering the actual workers (the ones who can see what's happening) to bring ideas up (if not effect them themselves). Every ToC implementation I've seen has been like the Lean one above, management (primarily) insisting on setting up complex observation techniques (because we need all the data!) and then issuing directives on what to change. Instead of, you know, actually observing themselves and encouraging workers to observe and improve. And like the Lean example at that old office, there was no incentive for the workers to participate. There was only punishment to be doled out if they failed to comply. Great way to win people over.

With regard to the others, I think it's worth noting what they brought to the table and where they ended up failing.

Royce's paper was presenting a kind of assembly line (the "strawman" waterfall model) that people wanted to apply to large scale software development. He then went on to elaborate on the issues with it. Some of the same issues, as it happens, that face real production assembly lines: late feedback, limited feedback, gross potential for producing the wrong thing or building it incorrectly and only discovering it at the end, forcing rework. Management and people like clean presentations. We like to think that we can have a nice and tidy flow and things will work correctly. Royce's elaboration on the model shows how to introduce the feedback needed to actually respond to when things go wrong. But like you said, people saw the diagram and ran with it instead of considering the rest. Offices still publish Waterfall-based development processes today, I know, I've had to talk them out of it. It's pretty and tidy but a failure in the real world, and a failure of planning.

Plans are worthless, but planning is everything. - Eisenhower

Making a pretty and useless plan is a kind of managerial masturbation. Temporarily satisfying, but produces nothing. Effort has to go into making real plans, even if they fail when they hit reality, because they'll prepare you for that reality.

Agile was similarly corrupted. See Scrum and XP. XP was cargo culted into, it seemed, nearly every software shop in the 00s. No understanding of why the techniques worked (for some people), only an insistence that they must be done. If the people foisting it on the workers had bothered to ask, "Do you want to try pair programming?" they may have gotten some yeses, probably a lot of noes, and a few ehs. Some of the workers may have tried it and loved it, others hated it, and in the end the teams would settle into the practices that worked for them. Which was, you know, the point of Agile (now lost). And yeah, SAFe can die a fiery death. I'll bring the gasoline. It is an abomination, and a blight on our industry. Like with Waterfall, it's more about creating an inflexible plan than planning and responding. The antithesis of the intent of Agile. It will (and in my experience does, even when done "right" per the consultants) provide a boost initially (new processes always seem to) and then devolve quickly into meeting hell.

DevOps has been, to me, one of the more tragic corruptions. Perhaps because it happened so quickly. TPP very quickly led to companies listing "DevOps" openings, which demonstrated a complete and utter failure to understand (assuming they read) the book. But it's also tragic because the idea is so fundamentally simple that corrupting it is almost like having everyone insist that 2+2=5. Rather notable that the Wikipedia page on DevOps manages to not even mention The Three Ways, which are literally the foundation of the idea. Instead it's primarily focused on techniques.