If you are building a product with a very close partnership to the end user with a small, experienced team who share a both a common view of the world and a common definition of success then scrum can work very well. Although, ANY methodology can work well in that environment.
The further away from that ideal the less successful scrum will be. Do you have a team of mixed ability? Scrum will have trouble because you are supposed to view everyone’s opinion as equally valid (but that new grad just doesn’t know as much as the grizzled veteran and scrum doesn’t accommodate mentorship).
Are you one or two steps removed from the end user? Then you are going to have problems because scrum demands a tight feedback loop with your user so if the “product owner” needs to launch a three month “customer survey” to answer every question you have many sprints without any meaningful feedback.
The fundamental truth is you can dictate what is built, or you can dictate when you want it. You can’t do both (because any meaningful software is by definition novel).
Scrum tries to say “deliver every sprint” without being opinionated about what get’s delivered. That can work with a tight feedback loop with the end user, but invariably product managers, sales, and business strategists get involved and they all want to be able to promise Things by Dates (“we won’t hold you to the dates, honest”) and that’s where it breaks down.
All of this is before you even get into the cargo cult of points poker (the value is in identifying mismatches in shared reality, not in sizing the stories) or stand ups (which only work if you are all trying to deliver One Thing).
Finally factor in that early adopters or scrum were actively looking for alternative ways to develop software beyond the “conventional wisdom” of waterfall whereas now everyone views agile/scrum as conventional wisdom and it’s unsurprising that most people have a decidedly subpar experience.