One reason is in the documentation for the MEMSIZE option:
Note: Setting MEMSIZE to MAX is reasonable only if consumers of large amounts of memory are not likely to become active after SAS has started. For example, if multiple instances of SAS are running concurrently, and all of these instances are started with a MEMSIZE value of MAX, one or more of these instances can encounter out of memory conditions, or, the operating system can run out of available paging space.
You may not do it but it is very easy to have multiple SAS sessions run at the same time, especially if running BATCH programs. I have run as many as 25 batch programs concurrently (but not with such a large Memsize setting).
I have the luxury of not working with "large" data sets so have never actually run into a memory limitation. YMMV.
In most cases, SAS is used in a client/server environment, where multiple SAS processes will run concurrently on the server and have to share the available memory.
On the SAS server I administered before retiring, the workspace server had a memsize of 512M defined, as we had to accommodate up to 50 concurrent workspace servers, the whole EBI backend (Java is a massive resource hog!), and the batch jobs with 128G of physical memory.
You need to remember that SAS runs not just on PCs, but on also on large servers where memory is shared across many users, so having a fairly low default setting is a good compromise.
The default 2GB setting was increased a while back I seem to recall. On our main SAS server I've currently got it set to 6GB and that appears to be fine for most users.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.