This advice mainly applies to Windows file server environments and where your application has a tendency to frequently chain to one or more particular programs. RUN and LIT programs are fetched from disk as needed and flushed after use (with the one exception being RUN.LIT). They are not cached in memory automatically (like SBX routines are) out of concern for the confusion that creates in development environments where you are frequently modifying and re-running programs. It is also very difficult to "guess" an optimum strategy for caching RUN files, since usage patterns vary spectacularly among applications. But it is easy enough to create a CMD file to LOAD your most commonly used RUN and LIT files before starting the application.

Most modern systems are memory rich (or should be, given the low cost of memory), so you can probably afford to be "extravagant" (by traditional AMOS terms). However, there is obviously a point at which it becomes more efficient to allow the system more memory to use dynamically as it sees fit than to lock it up storing individual copies of RUN programs for each user. (There is currently no equivalent of loading a program in system memory, so each user needs to load their own copies.)