Scrum is a reasonable baseline starting point for an agile team to iterate on for process. Like any process, it is bad as an inflexible, canned process instituted as a rote ritual.
> There is so much jargon and cruft around it; planning poker, story points, scrum master etc
Neither planning poker nor story points (nor even stories, which are a prerequeisite for planning points to be “story points”) are parts of Scrum. They are independent practices each with their own history, rationale, and associated bodies of knowledge that are frequently used within various development methodologies including Scrum.
> Software quality of what is built in the scrum way seems poor as it does local optimization and doesnt focus on long term.
“local optimization and doesn't focus on the long term” doesn't seem to be an inherent feature of Scrum particularly contrasted with “simple kanban”, which you suggest is the superior alternative.
> Simple Kanban seems more effective, do you feel the same way?
I think flow-based rather than increment-based methods are generally superior, and I am increasingly convinced that the Scrum Master and Product Owner roles defined in Scrum are counterproductive, demotivating, contrary to the Agile principle of collective ownership, and thus generally a bad idea, abd I think that while a daily checkup/plan update meeting is useful, I think most of the common ritualized use of the daily scrum (“did/doing/impediments”) is better served by a shared visual indicator, so, yeah, I tend to favor something more kanban-ish than Scrum (whether by that you mean Scrum-by-the-book or Scrum-as-commonly practiced).
> Is scrum built to ensure that program managers / product managers have something to do?
No, nor does Scrum even define roles for them. If they exist in an organization, they are outside the scope of Scrum.