Right that is how the word is often used in video game forums and journalism. But in the discussion of why scope creep might occur, it is important to identify the different roles in a game development company. The people determining the what and why (designers) aren't always (and very rarely are in modern game production) the ones doing the how (developers.) Without a good degree of cooperation, this de-synchrony can cause the scope creep issues. Developers likely are just getting Jira or Azure tickets from the product managers and designers, and resolving those tickets to the best of their abilities. 

Game publishers can be very much involved in the process. For the example you provided, Nintendo was very much hands-on in the development of Metroid Prime after many failures on Retro's part in other titles. So much so, that the perspective and visuals of the world were often decisions made by not just Nintendo as a company, but specifically Miyamoto himself. 

It is not some off-reality that publishers (or executives in the publishing company) tell developers that their games need to be as pretty as possible. Often first impressions are what sell a game and you'll have the marketing team in the publishing company wanting pretty visuals to make their jobs easier. Most players do, at least to some degree, judge a book by its cover. 

Piling on the effects til the resolution is blurry isn't really making your games as pretty as possible though.

I'm not saying publishers are blameless in the whole thing mind you, scope creep is a real thing, but the development studio bears responsibility too if they bog down the hardware with expensive effects. Sometimes less is more; the best looking games of last gen are still held by many to be prettier than most current gen titles.

The blurry resolution is a by-product of a lack of resources though. 

The way this works is like this: 

Designers, senior developers, senior artists, and project managers have many early meetings, some of which involve how a game will look. Designers and project managers pressure the senior developers and senior artists to agree to create as visually appealing a game as possible. The publishers also want this, for the reasons I mentioned earlier. The work to do this is planned out over time with project managers trying to keep the strict deadlines provided by the publisher. In the mean time developers might quit or be laid off. Early promises still have to be kept, because the epics, features, stories and sprints have already been planned, and the timelines are already made. The developers, with limited resources, and likely because they already over-promised to keep their jobs, try their best to provide each incremental feature (including visual features) they had agreed to provide in the pre-planning phase. Time runs out. The game still runs poorly. The game needs to be released. How do the developers make the game run well before release? Reduce scalable graphical features, like internal resolution. 

Now if the development company was well staffed, timelines were extended, expectations realigned, publishers were flexible, etc the end result might have been better. 

Nowhere in the process did the individual developers have the free-choice to say "oh I want to put as many pretty graphical effects in this game as possible." In fact, if it were up to them they probably wouldn't want to do that, preferring to create a performant game that had a clean look to one with flashy visual effects that are hard to develop in a strict timeline. 

An individual programmer on their own bears little responsibility, but in a larger sense members of the development team who make these calls and over-promise in the first place do.

If the systematic incentives of the organizations you are part of are designed that way, then one's capacity to push back is very limited. If the decision makers (mostly executives) are saying "do x" you're not going to get very far in saying "we can't do x." That's a quick path to unemployment. Your best bet is to say "in order to do x we need n resources" and the response would be one of the following: "oh then don't do x, it's not worth the cost of n resources", "oh then we will provide n resources", or most likely "why can't you do x without n resources? Why isn't n-m resources enough?" In organizations that fail at achieving their goals, usually it is the third response. The developers in this situation are making a rational decision, "save my job for now, maybe be able to achieve x without n resources, and if not -- deal with that when we get there." 

This is how software engineering in a for-profit system works in almost any organization, but its very much exacerbated in video game software companies. 

If you have to make impossible promises to keep your job, then you should probably leave that workplace for your own good.

Such conduct can only continue as long as people tolerate it.

Every single corporation over a certain size-threshold that employs technical staff has this to some degree. It's systematic. It's caused by people who don't have technical expertise having positions of authority in determining the production of those who do. 

But yeah, in a free system where the mass of the population didn't have to labor to survive you probably wouldn't see this happen as much, because people would just refuse to work with those who don't familiarize themselves with the technical constraints when planning. Even in our current system a way to mitigate these risks is to make sure there are people in the decision-making process with actual ownership/authority who do have the technical-expertise.  

The system is definitely flawed and ultimately to blame, no arguments there.

If we do that, we would all be doing anything else with our life other than working with technology. Late-project crunches and keep repeating cycle of oversized escopes are fundamental part of a programmers life. Best no mistake it happens in everything companies, even the healthier ones. Just yesterday I finished in 7 months with a escope that needed at least 12. It was extremely intense and the team is all but exhausted. Have everything planned worked? Of course not! But we delivered a minimum viable product nonetheless 

It's an already expected part of our career, kinda. Software is really hard to estimate, and is a more hand-made/manufacturer kinda of job, so how long something takes to develop will dramatically vary 

For software engineering we can, close to deadlines, stop developing some adjacent features to focus on more core/critical ones. Games absolutely do this also, but the results tend to be more evident/jarring because sometimes content cannot be cut completely, we can see some areas/levels being pretty barebones as a possible result of deadlines finishing

Truth is software engineering is easier to plan and better to work if we think of it as service instead of product. A product needs a clear cut and release date, with a defined and specific and fixed escope and a place to start and finish. You can add some stuff later, sure, but it can't be big or major

This might work in something like a movie that takes 2 hours, but for games... nah. Some developers mitigate this doing things like early acess, to varying degrees of success 

If it happens enough that they feel like they need to come out and defend themselves, they must be aware of the issue.
UE5 has at this point, a reputation for badly running and optimization with games.

It cannot be that every single dev that uses it somehow is just poor at optimizing their games.
At some point, you need to look the product and the way it was designed.

Like you pointed out, its probably working as intended.