Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.
We can save 100 lines of code there by coupling 2 slightly related things forever (and arbitrarily choosing this criteria for division as the most important).
I've made game before I knew OO programming. I haven't knew it then, but I used Interpreter Pattern - there was data model, with a list of records, each record had some enums deciding how game logic should handle it. There was main loop updating the model using these enums to choose logic to run on this record.
It wasn't pretty but it worked, I was able to modify it however I wanted, to choose logic to run on some record basing on enums, other atributes of given record, attributes of parent records, or of colliding records, on whatever I wanted basicaly.
Then I rewrote the game to use OO design (I was enthusiastic- this is exactly what I need - I thought). It turns out that I had to choose arbitrary divisions. I can divide game objects into Solid and non-solid, Static and Movable, Visible and Invisible, and also Smart vs Dumb Objects. Which division should be first in class hierarchy? All the rest would need to be duplicated anyway. SmartMovableVisible, SmartMovableInvisible, SmartStaticVisible, etc... Ugly.
Inheritance solves part of the problem and leaves you with inconsistent solution.
The real solution is strategy pattern, and composition over inheritance. It can be done just as well in languages without inheritance (but with lambdas).
I wrote the OO game in C++, but I avoided multiple inheritance, because there were warnings everywhere: "don't use multiple inheritance". And I don't think it would be much help in the end.
Another thing inheritance doesn't solve - when you want to choose which logic should run on your "object" depending on dynamic conditions.
For example I had ParticleEffect abstract class, Smoke and Fire derived from it. Fire reacted differently to collisions with stuff, than smoke. Fire partices were smaller with each frame to simulate flames, smoke was getting bigger and more transparent with each frame to simulate, well, smoke.
Then I wanted to make fire that turns into smoke after a couple of frames.
Solution 1 - merge both classes, make enum field inside, switch it after a couple of frames [not OO design - behaviour depends on fields not on classes]
Solution 2 - destroy fire object after a couple of frames and create new smoke object in its place [unnessesary allocation and deallocation is bad in games, also this complicates identity - for fire and smoke it doesn't matter, but for player and bullets it's important - I need to ensure player isn't hit by bullets he shoot, that's achieved by keeping "parent" pointer in each object, when the player is recreated because he got new behaviour - all the pointers are wrong and need to be updated].
I can't change class of object dynamicaly, so all the OO divisions are static in time, I have to workaround class hierarchy to model my problem correctly.
Another thing - in collision detection, the logic to run should depend on both colliding objects types, and some of their fields. With OO I have to workaround this again (because most OO languages are single-dispatch).
Another thing - OO data is much harder to serialize. Structural data allows banal serialization. This is solved in some languages (like Python or Java) by providing serialization in the core language, but in C++ or javascript serializing arbitrary object graph correctly is nontrivial. Serializing list of records was trivial even in Turbo Pascal ;)
"Give me an object like Foo, but with this one little thing changed."
Compression is a little dangerous because it requires the programmer to understand a fair amount about the context from which compressed code will take its meaning. Not only does this require available source code or excellent documentation, but the nature of inherited language also forces the programmer to understand the source or documentation. If a programmer needs a lot of context to understand a program he needs to extend, he may make mistake because of misunderstandings.
(from Patterns in Software, which is a really deep if long-winded book)
The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
Instead of
foo.WriteToFile("/tmp/foo")
You might write:
file.Write(foo.Representation()).
I promise that most inheritance in the real world is attempting to reuse something like "WriteToFile". "I wouldn't want to copy-paste the file-writing code, so I'll inherit from something that can write itself to the file." No. Don't do that.