Most of this is from the edited out portion of my original post. I edited it out because I thought I came up with a reason for why they wouldn't be able to simply unpack the textures. After reconsidering, even that wasn't a valid reason (see last part of this post).
Some using declarations (these terms have other definitions, but these definitions are what I mean in this post):
Texture packing - packing a bunch of small textures into a big texture
Texture pack - the big texture
Texture packing is usually done as a Luke-warm performance optimization to cut down on the # of batches (and thus increase the number of triangles per batch), and so decreases CPU overhead. I say Luke-warm because most of the time it only offers a relatively small gain (though does allow for better scaling for future hardware), so it usually isn't something worth making major sacrifices for.
The primary problems with it are:
A) AA won't work
B) You can end up actually hurting performance quite easily since you're packing a bunch of small textures into one big 4096x4096, or 2048x2048 texture. That means if all you need is 1 64x64 texture from a texture pack, you still have to load the entire thing in.
In cases where you can ensure that almost every object is both unique, and confined to a small area, that's when you get the best performance boost. But if you have a decent physics engine (as HL2 does) that will never happen. It's very possible that the user will bring a whole bunch of objects from different texture packs into one room, so that not only are you not saving on batching, you're also transferring several thousand times the amount of data you're using.
The fact that the optimization has a pretty bad, and not all too uncommon worst-case scenario, and only a mildly beneficial best-case scenario (when levels are so small that you can fit all the textures into a single pack) is reason enough for most developers to not do it (the technique isn't anything new, after all). You could very easily end up hurting performance with this "optimization", and you're losing AA too, not a very good deal IMO.
Texture packing of this kind is usually (and should be) done automatically, transparent to the content developers (artists). It's a pretty simple process, and just as easy to undo. All you're doing is making every object that references one texture reference the texture pack, then modify the texture coords to the correct position in the texture pack. Undoing this is simply a matter of taking out one of those textures in the texture pack, creating it as a separate texture, and making every mesh that uses the texcoords of that texture point to the separate texture with a (0,0) offset. After that, no more AA problems.
But, it has become clear to me that Valve isn't doing it as an optimization, but as a way of reducing redundant wrapping of textures. Stuff like having the same exact floor tile repeated a thousand times across the floor could easily benefit from having a texture pack of different floor tiles (of the same type of course) that could be readily substituted in to provide a more natural looking floor with cracks and such. But I still fail to see why this leaves the content creation side of things - there's no reason to do all the offsetting in vertex shaders if the offset isn't going to change (and I don't think it should, but Valve artists might disagree with me on that) during normal operation. And if it's not in the vertex shaders, a simple toggle in the config settings to allow the user to force texture unpacking should solve the problem and require minimal time and effort on Valve's part.
But if for some reason Valve does have all the texture packing stuff in vertex shaders and such (and I hear they have quite a few different shaders), it's understandable that they don't have time to go back through everything and provide a separate, un-packed version of the same shader. But then the question of why they didn't think of this all along comes up.. all these problems have been well known since about as long as HL2 has been in development, if not longer.
But then, I know Valve knows all of this, so I'm quite bewildered..
)
