I don't think this is exactly true in Armory's case. We have attempted to jail Armory using cgroups but during database rebuilds it fails if the memory restrictions are too stringent (<2GB in my testing). Additionally, if there is swap on the system, it appears the system will use the swap before asking Armory to relinquish any of its used memory, causing other processes on the system to hang waiting for I/O.
Both are obvious symptoms. If Armory is aggressively asking for memory it will take priority over processes in the background or that aren't requesting as much I/O. That's basic OS optimization.
As for memory requirements, Armory expects to have about 2~4GB of RAM at its disposal for it's own scanning needs. The rest is mmap'ed files requested by LMDB. That's controlled by a hardcoded value and will probably be dynamically assigned in the upcoming version.