The AMD devs have downplayed the importance of this state tracker for the hardware drivers (r600g, etc) because xf86-video-ati isn't too much of a maintenance burden, and not nearly as complex code as Linux DRM or Mesa. So they aren't eager to jump into the generic-xorg-driver soup because the soup they've got is already fine, thanks.
My observations agree: the commit frequency in xf86-video-ati is pretty sparse these days. It was atrociously huge when they did user modesetting, but KMS takes the ugliest code out of the DDX.
If XA matures enough, maybe it literally won't matter whether you pick XA or xf86-video-ati, since both could be viable options. But my feeling is that the AMD devs will keep on supporting xf86-video-ati because that driver works, and unifying the DDX across the drivers doesn't alleviate many burdens for most developers. And as always, the Linux DRM and Mesa continue to be the projects where most of the grinding happens.
AFAIK the XA state tracker is just an interface for DDX drivers (like vmwgfx) that exposes common acceleration paths (like XRender) through gallium pipe drivers. It's versioned unlike gallium, so one can build it independently. It won't replace the whole DDX driver, but will unify a lot of code and decrease further (after KMS) the size of DDX drivers (like xf86-video-ati).
For ati DDX driver I'm not so sure if it will ever be unified. Previous Radeon GPUs (R300-R500) had 2D engine which is used to accelerate things like EXA (I suppose, I didn't study the code thoroughly), which cannot be used with gallium (it makes use of 3D engine). R100-R200 are not even supported by gallium. This state tracker would only be used for modern AMD GPUs (R600 and above). Because of that, the benefit of using XA wouldn't be so huge for xf86-video-ati. Maybe the driver should be splitted to one for pre-R600 hardware and one for R600-and-above?
For ati DDX driver I'm not so sure if it will ever be unified. Previous Radeon GPUs (R300-R500) had 2D engine which is used to accelerate things like EXA (I suppose, I didn't study the code thoroughly), which cannot be used with gallium (it makes use of 3D engine).
There is nothing wrong about using the R300 3D engine for 2D operations. r300g has low CPU overhead, which might be a win.