Having done game software testing, I know for a fact that the big AAA studios (or at least the ones that I had worked for) do overnight testing as part of stress testing where the game is deliberately left on overnight. While I had seen crash bugs deliberately left in games, it was never the crashes that occurred because of extended playing. Also some overnight crashes that I personally encountered as a tester were the result of the game pushing the system too hard such that it just overheated.

Y we have a system thumb drive at hand to reload W10, starting from ground zero(0), then proceed to our BU PC(s) to continue as usual.

Even the sleep deprived thing is not justified, there are many reasons why you would leave a game running overnight, the biggest being save point starvation.

Two examples of games where I did this was Disgaea where it took too long to finish an Item World level, so I'd just pause the game, shut off the monitor and speakers, and go to bed, then go to work, and come back after work. Another example was the Gold Saucer part of Final Fantasy VII where you were fined GP for using the save point, but I couldn't finish it all in one go. So I'd leave the game running, go to bed, go to college, go to my part-time job, eat dinner, do my homework, then play a couple hours before going back to repeat the cycle.

Although I do recall a few games that would do this kind of hard lock back in the day if you failed the copy protection test from early DRM (though the term wasn't coined yet). Sierra was at least merciful in that they'd just make the game quit (and games like Gold Rush had long load times, 5 minutes to boot up from 3.5" disks). However others were more sadistic for the crime of alleged piracy. That included fat-fingering the "enter in the word from the manual" copy-protection, or for daring to try to play on a backup disk instead of risking the original winding up under the coaster of your chair, and not having the original handy because you put it in a safe place. The game then says "please insert your original disk", so by the time you dig it out a timer has expired and the game assumes you're a pirate.
Also no internet for easy access to cracks back then.

Reminds me of how one specific version of Super Mario 64 (I think it may be the Wii Virtual Console version) had a bug where, if you'd stay in a particular stage long enough (like multiple days), the platforms would rise because the floating point rounding mode had been set incorrectly. (This particular bug is largely harmless, but it did, I believe, make it possible to beat the game (70 stars) without pressing A.)

I consider this sort of save point starvation without even a quit save to be bad game design that, if it happens in a mandatory section, is enough to ruin a game. Offenders here include Arc the Lad 2 (one area required 2 hours without a save, even though they put in a rest spot in the middle, when I played it) and Final Fantasy 3 (the rather infamous final dungeon).

This sort of issue is also why I never got deep into Lufia 2's Ancient Cave. Fortunately, Lufia: The Legend Returns added a quit save, making its version of the Ancient Cave actually playable. (By the way, in TLR's Ancient Cave, it's fun to start on floor 101 once you get the option; also the bonus for Retry mode carries over, unlike in Lufia 2 (where you might choose to wait for Gift mode).)

In addition to what Dtgreene said about that being a problem unto itself, what did you think I meant to do by preceding with "only fallowing an auto-save"? I nipped your problem in the bud from the start.

I think any feature can be done correctly, but some are harder to justify or implement. This reminds me of the Genesis X-Men game that required the player to reset the console to move to the final level, which is an interesting but IMHO poorly executed.

That sounds like something that was just left in the game as either a "Known Issue" or "As Designed."

One crash bug that I encountered personally though that was just left on the game was a situation where you had to strike a killing blow on the boss at one exact spot while jumping in the air and facing towards the left. Even after we narrowed down the exact circumstances, it wasn't easy to reproduce.

I don't want to go into exact titles, but the reasons why were always because they were very hard to reproduce. The one that I mentioned in post #23 (trike a killing blow on the boss at one exact spot while jumping in the air and facing towards the left) was originally found by someone else, but they were not recording their playing so nobody could go back and see what they did. I got the fun task of trying to reproduce it, only knowing that it was during a specific encounter. It took me five hours to reproduce the crash and even narrowing down the exact cause (due to what wasn't causing the crash), it was determined to be really hard to reproduce.

The programmers were always concerned that in the process of fixing one bug, they'll introduce either a bunch more or a crash that is more easy to reproduce thus why they'll just leave some bugs in if they're hard to reproduce or considered to be minor.

Some games are total beasts though in that no matter what testing threw at it, the game would just carry on.

Ah, so you meant intentionally left as in accidentally there but decided it wasn't worth the trouble to fix, not as in actually introduced on purpose. Thought there were any examples of the latter.

They weren't acceptable when the Two Guys from Andromeda & Roberta Williams were working on games, they certainly aren't now.

I don't know of a case where a bug was intentionally introduced and just left in the game. If a programmer is disgruntle enough to do something like that, they're certainly not going to tell anyone in the testing department.

Hardlocking is like bricking, and shouldn't ever happen.

Though i hear in the trucking industry, they've put in computers that will SHUT OFF THE ENGINE AND LOCK YOU OUT after N hours, ready or not.

I'm sure that won't cause issues ever....

The Super Mario 64 issue I'm mentioning is actually an emulation issue. Thing is, Nintendo's emulator is using the wrong floating point rounding mode, and that's enough to allow errors to accumulate over days until the platforms are high enough to allow the A button press to be skipped.

Dragon Quest 3 on the Game Boy Color has a bunch of bugs, including a minor bug where, if a character loses max HP while playing Pachisi, the character's current HP may exceed the max.

For the US release, Dragon Warrior 3, they fixed all the bugs. However, in fixing the minor bug, they introduced a major bug where, if a character loses Strength while playing Pachisi, the character may gain a huge amount of XP, enough to break the game (and, in particular, enough to make it feasible to skip the Magic and Final Keys).

Hardlocking isn't as bad as bricking or data loss; if a game hardlocks, you can still start the game up again after (uncleanly) shutting it down and expect it to still work.

There is one browser game I've played where, once you get a certain (rather sad) ending, you can no longer play it in that browser unless you delete local storage from the site; that's closer to bricking the game. (And yes, this is intentional.)

There's also a game (the second Pool of Radiance game, based on 3e rules but not allowing the player to make character build choices) where, if you try to uninstall, it wipes out your hard drive, I believe. (This was fixed in a patch, I believe.)

EDIT: SPOILERS AHEAD FOR DDLC AND PONY ISLAND. DON'T READ FURTHER IF YOU HAVE NOT PLAYED EITHER OF THESE AND INTEND TO.
.
.
.
.
.
.
.
There are other ways, but I could see it as an artistic choice to actually force a hardlock in a game like ...* (moved to the end of the post) that actually break the 4th wall and require you to modify or delete files to complete the content. Your question wasn't "Is it necessary," but "Is it acceptable?" If you're into the 4th-wall-break meta-game style of games, then the answer is "Absolutely."

*Doki Doki Literature Club or Pony Island