Biggest difference between tech industry engineering and game engineering isn't the stack, IMO - it's the WORKFLOW. Games are made quite differently to most other kinds of software.

Game teams have many artists/designers, and it takes a LOT of iterations to get gameplay "right." Engineering can't be the only folks allowed to touch the build - we simply can't afford that kind of bottleneck.

Instead, engineers need to put tools in the hands of their colleagues, design them so it's easy to do the right thing, architect behind the scenes so everything plays nice together, and then get the heck out of the way.

Thankfully, modern game engines are designed to facilitate that. They each provide some kind of "content layer" on top of the game's code, such as Unreal Blueprint. Designers can generally work in the content layer, using capabilities that engineers expose from code.

(I'm generalizing a bit - some designers are comfortable in code. Some engineering work happens in the content layer. Reality is always more complicated)

Content tools like Blueprint may not make the most performant thing. That's OK. Much of it will be shippable anyway, and game engineering is not about perfection.
It's about finding balance between iteration, performance and reliability.

Experienced game engineers know to grab the wheel when things look to be going in a non-viable direction. It's totally expected for engineering to introduce constraints, you just want to avoid doing it too early (limits design) or too late (after lots of content already got made)

This may help explain why game bugs are so wild. Designers make content using systems in creative ways. Engineers later optimize those systems and make them a little less flexible. BAM, now there's one quest where if you skip the dialog you get stuck in an unremovable banana suit

Anyway if you take anything from this thread, let it be that game engineering is less about the pursuit of technological perfection and more about conserving the game while you are still building it