Sure, but there should be no reason to make that call either. In pretty much every place GL_LIMITS(textures) is used, it would either need to be replaced with the fragment pipe implementation based limit or not be executed at all (eg. code that calls glTexEnvf or creates dummy textures really doesn't need to be executed when using arbfp). The only possible exception is SetupForBlit(), but I'm tempted to say we shouldn't be using that either when shaders are available. It's a pretty minor point though, and I'm not necessarily opposed to a separate fragment pipe based limit.
Yes, we can eliminate those calls, and currently SetupForBlit and the dummy textures are the only remaining cases. However, I prefer to keep all the limits in the structures, since replacing them based on the pipeline implementation will be messy.
In the end I think "Why is this code reading the wrong limit" is easier to debug than "Why does this limit contain the wrong value"