I doubt it. Generally speaking, object oriented programming is nearly everywhere nowadays. So even outside of game development, people are really used to OOP. Which makes sense, since it’s easy to describe logical structures in programs as relations between objects, each having their own state and functionality.
However, i’d say in game development specifically, not having an object oriented mindset causes lots of inconveniences. This obviusly depends on what you are doing, but more often than not you have, for example, a couple characters fighting each other. Each of those characters has its own state (attack, hp, name, …), as well as model, animations, animation state and so on. Or in other words, each character is its own “object”, having an internal state, and being able to do certain things, like attacking or changing its state by, for example, losing health. This makes working with them very convenient, especially as the game grows.
It also has the added benefit of making things highly modular. Need some follow camera? Create it as a script and use it when you need it. Want a character to be able to wallrun or have x-ray vision? Add this functionality as a (script) component to those characters allowed to do so, but not to others. And so on.
I’d say, rather than being traditionally object oriented programming, in Unity you rather write components which you then attach to (game)objects to give them new functionality. Within these scripts, you can write your code mostly like you are used to, with few exceptions, like getting information from other scripts or objects.
There is also DOTS, which is less object oriented (it’s data oriented with some OO conveniences) but results in highly efficient code. If you plan on having a look at something other than purely procedure based programming, you may as well directly take a look at the new data oriented technology stack. DOTS is made up of 3 parts, ECS, Jobs and Burst.
ECS is the data structure, so to speak. You create “components”, which are structs with a single value (like health, or a position). You can group some sum of components to create “entities”, and you define executable code, called “systems”, to run on components (for example, making all entities with a position component move). These systems run using Jobs, so they are generally multithreaded more or less by default, and completely safely. Using jobs enables you to use the burst compiler, for a free >10x speedup, often even more! The whole thing creates insanely efficient code.
This may be interresting to you, since it requires less of an object oriented mindset (you mostly work data of the same type per system, like on all “positions” for example). So you may even find it more intuitive to use.
Probably not exactly the answer you were hoping for, but i hope it helps nontheless 