It is not as easy to see as with GraphQL because the term is overloaded/ill defined, and there is a large number of ways to interpret how OOP should be used. Probably why it took so long to realize the issues and move away from the concepts.

Sidenote: with GraphQL you will also see a lot of people who are scratching their heads saying "Surely I must be doing something wrong, it can't be this bad. I just don't understand what that something is.". When the users of your tech have difficulty even articulating what the issues are, that's when you know you hit the anti-design jackpot.

In terms of whether a shift away from OOP has happened, you can look at how modern languages/language features are designed, and how "best practice" has changed: they are explicitly moving towards data-centric design with FP concepts(e.g. ADTs, "plain" functions, ironically similar to C), and moving away from dynamic dispatch. And when they do implement dynamic dispatch, there are warning signs around it, it's not considered good practice (see e.g. trait objects in Rust). Encapsulation/visibility is now treated as an orthogonal concept (as it should be), the whole getters/setters visitor-pattern/proxy-pattern/etc nonsense is essentially binned, they're not even mentioned anymore outside legacy codebases and Java shops.

In terms of what the issues are, it's inheritance/subtyping and dynamic dispatch, IMHO the two hallmarks of OOP. (I know, purists will point to a different kind of definition, but in my experience this is how OOP is used in practice). There are some additional oddities like "design patterns" and "encapsulation" and whatnot, but I would consider these as secondary fallout issues, stemming from the two major problems and a zealous shoehorn-y attitude. This attitude BTW is characteristic of hype waves.

Ok so what are the issues with inheritance?

From a type-theoretic point of view it's variance. When you have a (parametric) polymorphic type and you shove a type into it with subtyping relations, you'll get problems. The classic example is the array of Animals/Dogs/Cats case. At the time of the OOP hype's peak, advocates kept bringing up this example as if it was a tool to understand OOP better. But instead, it's a great tool to understand how subtyping can lead to intractable reasoning about variance for no good reason. "Composition over inheritance" is now commonly understood as a good preemptive tactic. (Composition is not an OOP concept.)
From a data-structure point of view the issue is fields. Can/should a subtype access the parent's fields? How about multiple inheritance? Throw in the private/protected/public trio and you'll get pieces of code so hairy that you'll just end up writing wrappers around it instead of trying to understand it.

Sidenote: I do want to note that there is a single use case of inheritance I know of which actually makes sense, but it's very specific to C++. It's "plain" (non-virtual) inheritance for the purpose of composing memory layouts while still allowing pointer aliasing. Row polymorphism (see e.g. TypeScript) is also useful, but it's difficult to argue that it's an OOP concept.

Ok, what are the issues with dynamic dispatch?

From a code design point of view the issue is, for lack of a better expression, missing alternatives. OOP-supporting languages "solved away" ADT-style dispatch (enum data structures+pattern matching) which has a very natural mental model, and replaced it with things like double dispatch and code-data coupling. When I'm writing a piece of Java code and I want to express that there are 3 known states that the data can be in, I have no choice but to use an abstract State class, add dynamic dispatch and either tightly couple the state-handler code with the state definition, or bloat the code further with double dispatch. I literally cannot do anything else, unless I start writing completely non-idiomatic code.

From a code organization point of view the issue is "open sums". Open sums(aka interface-like views on concrete implementations) do actually have their place, however OOP encourages their use way beyond what's reasonable. This results in code that's very difficult to read, it becomes time consuming to piece together what the hell a function is actually doing, because all you see are calls to interface functions. What you need to do as you read the code is essentially "close the sum" and substitute the various possible implementations into the control flow, which results in a conceptual blowup of the possible states of the program. That, or you just observe how the code is behaving at runtime. I'm not ashamed to admit that I've done the latter quite a few times with legacy codebases because the code itself was in a worse shape than the execution stack.

From a debuggability point of view the issue is similar, it's an intractable CFG. During debugging you need to re-build a conceptual mental model of "runtime behaviour" where you need to find the conditionals that actually decide what concrete objects are being dispatched to under what circumstances. Anyone who has any experience debugging such pieces of code will know exactly what this means.

Sidenote: The FP hype can also result in very similar CFG issues, but this time it's due to overuse of lambdas/closures.

In terms of the damage.. well, it's the countless hours of writing, maintaining and debugging these codebases. It's the lost dev hours, the lack of progress, the "stalling" of codebases after becoming a giant mess. I'd wager it threw back software engineering as a discipline maybe 10 years and by extension humanity as well (I wanted to say more, but the natural sw company/startup birth-death cycle mitigated a lot of the legacy-buildup issues, at least from what I've seen in my career).