There are a lot of possible "right" and "not-right" ways of programming.

As you said, OOP aims to structure your code in order to do not lose your sanity when you will take back your code to code new features. Actually OOP is great for code design, watch about Design patterns and SOLID architecture for example...

BUT this is not the only reason. Let's suppose you wanna implement new functionalities like "police" or "bike" in a future. Actually you obviously can create a class and invoke that class from main.py. But when you implement a lot of these features you actually will have a gargantuan function which calls different classes in different modules and each time you have to modify one of these modules if class is not well written.

The best principle you can follow is Single-responsability (S of SOLID architecture), this means that one function has ONE responsability, so if car_generator is a function that generates car, actually should not generate bikes. In this way, when you will read your code again you know that car_generator doesn't implement bikes.

Now, you could think "Well, I rename car_generator in generator and I fix the problem". Actually you can, but the point is generator must do only one thing. When you add code in generator to check how many vehicles are in game in a specific time, you broke this principle and in 3 months you will forget that you added this functionality in this function.

Re-read your code now and think "do this function actually does only one thing?", if answer is yes, you can go over, but if in a future you program to implement a vehicle counter, you have to manage fact car_generator actually already does one thing, it creates vehicles.

You can extend this fact to modules too. main.py actually is like a wizard . It must invoke other functions and maintain a "logic" in your game. You can obviously instantiate objects in it, but what if one day you will have twenty classes each one creating twenty vehicles?

The problem is that car_generator is more a function which generates car so it should not stay in main.py. In this way, when you think "ok, I have to create a car" you know you have to visit and modify Car.py and not main.py.

Another thing is that actually you are "thinking" in C. That's really cool to start programming, but actually OOP is great cause of inheritance and polimorphism, two principles of OOP. You will understand why you prof. did this when you will meet these two principles.

I REPEAT: Your solution is not actually "clearly wrong" or "clearly good". Depends on what you will implement next. If the course teaches you that, probably it's because the tutor after years of coding found this is the most clear and beautiful way of creating this kind of things. I suggest you to read books and watch online tutorials of clean code and Design patterns to understand what your teacher is "implicitly saying"

Greetings