I worked in games from 2006 to 2014 on titles that I imagine are similar in scale & production to Oddworld or Dungeon Siege to something more like an EA or Rockstar flagship title towards the end of my career in the industry. On the latter end of my career we had dedicated build/release teams, dedicated mocap technicians, networking/multiplayer teams, international/distributed teams, finer-grained tools teams, dedicated DLC teams, etc. We had interns, we had to prepare for more media appearances, etc. It was a completely different environment. Again, I'm not trying to disparage the games they worked on, my point was the environment in which they were created.
I admittedly don't know firsthand what Thief or Dungeon Siege were like but you can see the difference on Mobygames; these both have ~250-300 credited in total versus Assassin's Creed (and "only" the 2007 version) which has ~900 — it only goes up from there. This is not a rock solid comparison but it's probably a decent proxy to describe the scale of production. You could maybe argue that a title like Assassin's Creed had a bloated team, but as an IC that's not really in my control.
But in more concrete terms what I mean is that in the Dungeon Siege/Oddword environment, sure I could have maybe said to my team — I'm going to rewrite "x" because it's not efficient enough, and then go heads down for a while and try to solve this problem. I didn't have that same luxury at the other end of the spectrum. On a smaller team I could maybe say — hey, I think we should drop C++/OOP because of "reasons", and have a somewhat realistic chance of persuading the team. This was unlikely to be taken seriously at your EA/R* type company.
Beyond the games industry I'm not going to be taken seriously suggesting to my big tech employer to rewrite everything in Rust instead of Java because OO is evil or it's non-performant or whatever. As far as polymorphism and clean code go, I sometimes find value in leveraging these if they make sense. I may anticipate some persistence-layer migration in the future or feel defensive about the next few intern project and want to try and have some sort of guardrails to limit their blast-radius. Virtual functions are non-performant, Jon or Casey may argue, and they'd be right in their respective domain — but it's not really applicable in mine; even if I were to theoretically drive _my_ service latency down to zero, my end-user would notice no difference as most of the latency is spent on downstream services. Etc, etc.