I think of it in analogy to math. OOP is like topology - it's definitely useful in some cases, it's not too hard for an experienced mathematician to get the basics, and yet in a lot of situations it's irrelevant and it doesn't really belong in the first class you take.
Being able to solve fizzbuzz is like doing arithmetic. If you can't solve fizzbuzz then you aren't going to be able to really get any advanced concepts. It's like you can't be a good mathematician if you can't figure out whether 351 is an odd number - you need to learn the basics first, even if "real math isn't about arithmetic".
Sadly, you can tell if you do a lot of phone screens that many people who graduate with CS degrees still can't code fizzbuzz. Our CS education is busted right at the beginning. It needs to get the basics right, like, can you write loops, can you write functions. Today it is failing at that.
It reminds me a bit of how I was taught basic economics, where societies go from barter to currency. Apparently this is not true at all, but it's a story that is easy to teach.
They are two completely different processes.
I have experience teaching kids Lua, and with the right metaphors and a little bit of backtracking and foundation-building, even complicated ideas like emulating classes and single inheritance can be understood and even implemented by young students.
If I taught them lua reserved keywords, and a couple little math tricks here and there, they usually would all bunch up everything into a couple huge functions, and their game would (sort-of) work but be impossible to reason about, and very painful to extend.
Introducing objects as a way to represent things that they want the game to do (draw things, shoot things, eat things, etc), it becomes clear to them that there is merit in structuring programs with objects beyond "shrugger says to do it like this!"
OOP on its own doesn't make much sense. You can't teach someone to drive stick shift if they don't know what a car is. Maybe you could, but that's probably even worse.