I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work with is _way_, _way_, more difficult than a non-OOP codebase that just directly solves the problem in a straightforward way.

OOP encourages adding layers of abstraction, indirection, and generic stuff that sounds great if you're trying to create some kind of generic underlying framework for everything. But it makes a huge mess when you're just trying to solve a specific problem, fix a bug, or make one tiny change. Now you have to debug trace through 65 layers of unrelated generic abstract stuff to try to figure out where/why something's going wrong.

I suspect one of the reasons that some new languages don't give you that gun to shoot yourself in the foot with is because the people that made them had worked on large OOP codebases and suffered from similar problems. They're making languages to more simply solve problems in a straightforward and direct manner.

Of course, you could do that with OOP. But people don't. Given OOP, (and that book of patterns that they found), they get fancy and make it way more over-complicated than it needs to be. The result is, ironically, unmaintainable software that takes way longer to work on, and has unexpected bugs throughout the system causing bugs in distant unrelated places - exactly the sorts of problems that OOP was supposed to address. I don't think that's an inherent problem of OOP, but just our human nature. We can screw up anything.

So new systems with more constraints can help reduce the ways that we can screw things up. And if you really need to get stuff done, the more constraints you can place on it, the better. Static typing, non-OOP programming, limited-palette artwork - it all comes down to less ways for you to screw it up, and easier to fix if you do.