Oops, I think I’m mistaken on the UE4 comment — that was the original reasoning for having AO use the ‘red’ channel of the texture, not for the selection of uv2. The addition of a vertex attribute here has never been identified as a relevant performance cost. There’s some extra memory footprint, but not much compared to the texture itself.
One example use case for a second UV set would be something like https://github.com/wwwtyro/geo-ambient-occlusion/, supporting per-vertex AO. In that case, as I show on this glTF example, your AO texture can be a simple 256x1 gradient and you’d use the UVs to index into that gradient. It works well, and cheaply, for something like a voxel model.
Perhaps a more common example would be something like this discussion, where AO information is concentrated around areas that would normally be seams in your diffuse and other maps. But I’m not a 3D artist, perhaps I’m misunderstanding that. I’ve also seen cases where users want to tile their diffuse/metal/rough maps but not tile AO, and (because UV slots are associated with UV transforms) the separate UV slot helps with this too.
tl;dr — I don’t see us taking away the ability to use separate UVs for aoMap. It’s unfortunate that this causes a conflict with lightMap, although that conflict has (so far) been fairly rare. There is a fair bit of interest in more flexibility in general here, and being able to allocate UV slots and UV transforms in more custom ways. I think an eventual solution for that would also cover what you’re referring to here.