I think it depends on application. For a video game, that’s what you should do. However, that’s not really advisable for a database where broken invariants might lead to corruption.
In open source software where you can throw it over the fence and say "no warranty", perhaps.
In commercial software where your users will say "Y" even when they have 16MB of RAM, have an awful time, waste your money calling your support in that unsupported configuration (and forget to mention it), and leave negative reviews - no, hard blocks make a lot of sense.
"The program won't start" is straightforward and a short script will quickly identify the real problem.
"On Tuesdays when I alt-tab to Backgammon, my save file is corrupted" is much tougher to immediately identify as out of memory.
Telling users no at the beginning yields far fewer negative feelings than letting them get invested and then experience a major problem, blocker, or just constant random irritations
