It is probably not practical that ATLAS will provide a complete LAPACK API (as it does with the BLAS) in the foreseeable future, both due to the algorithmic complexity of some of the operations, and to the sheer number of routines in LAPACK. It must be understood that adding routines adds to the inertia and maintenance costs of the package, and this additional burden must be offset by real advantage for the user.
ATLAS has so far only added LAPACK routines to ATLAS when we can make a performance-enhancing algorithm modification. For instance, we added the LU and Cholesky factorizations because we used the recursive formulations of these routines, which provides for better performance on pretty much any cache-based architecture.
However, when we have added such routines, we usually add the correlated routines even when a performance advantage is not supplied. For instance, upon adding GETRF support, we also added GETRS and GESV. As far as column- major routines go, we supply no better algorithm for GETRS or GESV than LAPACK. However, since these routines are very simple, and GETRF is very often used with them, we added them along with GETRF. The idea here is that their maintenance costs are not heavy, and real advantage is given to the user in that we have sped up GETRF, and if the factor and solve are all he needs, ATLAS will supply a complete solution.
The column-major comment points out another reason to add a routine to ATLAS: ATLAS supplies the only performance-aware row-major LAPACK implementation that I am aware of (I'm sure there are some, I just don't know of any that aren't simply using the col-major stuff, and thus performing terribly). It is possible that someone would want to add an LAPACK routine to ATLAS simply because they need a row-major version, and someone being motivated enough to write it would probably be ample justification to add the routine to the ATLAS tarfile.