These two cases are completely different. The script may eat a lot of memory because the JavaScript engine does not perform garbage collection as aggressively as it should for some native objects. The main reason is that the engine has no way to know how much memory a native object, such as an Image object, is consuming internally. A simple call to Image.free(), as I have described above, solves this issue in practice. Obviously, freeing memory blocks manually is not something one would expect to have to do in a dynamic language like JS. However, the PJSR is not really as dynamic as we tend to think, mainly because it is being supported by many objects that live in the C++ side of the runtime. This is a very complex topic, where I am investing a lot of my development time for the next versions of PixInsight. The SpiderMonkey engine will probably be replaced with something more manageable in future versions. Perhaps the V8 engine. I am investigating also Qt's V4, which looks promising. In a future version (maybe this year) we'll have an integrated C++ compiler in PixInsight (clang). When that happens, the JavaScript engine will be less relevant because PCL-based C++ code will be compiled and linked on the fly. In fact, the idea is that most standard modules will be distributed directly as source code, which will be built automatically on the user's machine.
The other out of memory issue is not reproducible. Well, it can be reproduced in your machine, obviously, but I have no way to replicate it on my working and testing machines, including Windows 10. The fact that this error does not happen on your laptop with the same data is telling us that it could be related to a particular system configuration. I know this sounds weird, but have you tried disabling your virus protection software? Are there other running background processes, such as system utilities?