GILDAS was designed to be fast and use little disk space. The consequence is that it is not as comprehensive as larger packages. In particular, it does not handle any ``history'' like AIPS does. You should then take care of what a particular image is really. All vital information is in principle correctly transmitted : axis types, coordinate conversion formula, projection information. Extrema may need to be recomputed.
Other drawbacks comes from the virtual memory concept itself. The maximum virtual memory a process can have is often limited by the operating system configuration. With modern computers, a reasonable limit of say typically 256 Mbytes corresponds to data cubes of 256 by 256 by 256 (as you typically access several data cubes at the same time...). Few instruments are capable of producing larger data sets however, and large computers would be required to handle these data in any case. These limitations can be partly removed by proper programming of the applications (i.e. reading subsets whenever possible).
GILDAS does not clean up things as for example AIPS does when you exit. Command files for the tasks are in principle deleted after task completion. But it is up to the user to delete scratch files and log files which are no longer needed. However GILDAS never creates data or work files without having requested a file name, so you know which files have been created.
Finally, GILDAS contains an increasing number of algorithms. It is always assumed that the user understands the basics of image processing when using these algorithms. They may not apply to your special cases. Although they are usually tested, some of them may still be in the development phase. A message in the HELP or in the parameter file will signal these programs.