Great question. They have pet features. Features with long estimates are targets for being cut. Give a long estimate, you risk not being able to build your feature.

I once asked, how long to add analytics to your code? (I wrote a one line utility that could bundle up objects and fire them off for you.) The response was "three weeks per event". Guess which part of the code didn't have analytics.

Now, at some level this is leadership's fault. They own the culture, but many of the engineers I worked with in games were the least interested in being a part of a team I've ever seen.

This and so much this.

To elaborate on your point, say a programmer and a designer brainstorm an amazing new jetpack feature for the game. They spend a day (when they should be working on less interesting but planned features) on a quick first pass and show it to their PM.

The PM asks how long it will take to complete, they say 3 weeks (2 days of UI/UX time to add the fuel bar, a week to tweak the feel and mechanic, 2 days of FX artist time, 2 days of artist time to make the rocket pack model). The PM says that the feature is unplanned and that is too long, so they say they can cut some corners because they really want the feature in and its more interesting than working on their planned tasks. The PM agrees because he wants the team to be creative and take control and pride over how great their game is.

In the end the feature stays in and takes 2 months of development time since it requires modifications to world collision geometry, each selectable player needs a differently modeled jetpack to fit their geometry, a jetpack upgrade system is added, loot box unlockable color customization gets introduced, bots need to be able to fly too and so pathing and behaviors need extensive modification, a tutorial needs adding, sound effects need designing and adding, QA has to do a pass of finding everywhere in the world that the jetpack can be used to get out-of-bounds and to avoid gameplay trigger volumes, and someone has to triage and fix all those issues. And I realized I probably vastly underestimated... do we slip, missing being part of this quarters revenue and cancelling our ad-campaign or have we just pushed into development hell?

This is why grownup software companies have milestones like “requirements freeze” and “feature freeze”, and strong project management leadership who enforce these things. Adding or changing requirements mid-project (or mid-sprint, if that’s how you roll) is very often harmful to a software program’s success.

If the people you hire refuse to build what you hired them to build, and you insist on paying them anyway, you've got a lost cause.

Insecurity combined with spinelessness causes people to give the answer they think their superior wants. This is a response that is trained by managers using microaggression.

I've seen people put low estimates on things so they would be able to start something knowing that once started it was likely that we would continue working on it until completion.