There's nothing wrong with simple code. In fact, the simpler, the better! Put all the complexity away into your data structures and make your code as simple as possible!
Abstraction is a foreign concept to exactly the programmers I was talking about.
It's also a foreign concept to most C programmers, who seem to love messing with string buffer pointers in the middle of business logic code.
Let the data structures do all the heavy lifting! OOP is an oopsie as it couples data and implementation too closely, which can end up with messy data and messy implementation(and more often than not, loads of boilerplate for getting and representing the data rather than actually doing something with it).
People say this like it's a slam dunk, but the problem is literally worse with procedural programming.
My favorite example of this kind of meme thinking is Linus Torvalds. He endlessly complains about C++ programmers and the quality of C++ code, but the source code to git is up on GitHub. I've seen it. It's horrible. Multi-Thousand line source files, pointers everywhere, macros calling macros with names like n_squiz. It's a nightmare.
Yes, there are genuine arguments against Oop. Mixing state and implementation is not one of them. Most of the complains I see about oop are unfounded and are based on "simple code" memes. But the code is so simple as to be horrible. Just because you can save 2 lines by doing pointer arithmetic doesn't mean you should.
This really is the big problem with the "simple" code debate. People use stupid metrics. Usually either lines of code or compute cycles, as if that's some objective proof that their code is good. It doesn't work that way. Never is the time (and money) cost of code maintenance ever considered.
The year is 1999. Imagine you just got hired to work at Id software. Someone has reported a bug with the way shadows and reflections are rendering. You look into the code and see
fast-invsqrt. You realize it's impossible to maintain and spend hours wrapping your head around how it works. You can argue that it's fast code - especially fast code that needs to run multiple times per frame, which is important. But you can't argue it's good code. It's neither simple nor easy to understand. And it's impossible to maintain.
I do see what you meant by "simple". It's easier to throw on a few extra if statements. This gets worse and worse if the default engine implementation isn't what you want, so you have to reinvent the wheel(flashbacks to Godot's 3D movement when I was trying to make Quake Style movement)
Good OO programmers rarely if ever use if