An alist is just a list whose structure conforms to a certain pattern. Overloading lists' function for when the argument is something other than numbers for alists makes as much sense as writing some very general tree code and giving its index function prefix tree behavior when called with strings.
Besides, that just wouldn't work if your alist is keyed with integers. Should (((1 . #\A) (2 . #\B) (3 . #\C)) 2) return #\B or (3 . #\C)?
I've thought about making alists work in functional position, but as Darmani points out, that would be ambiguous with integer keys. If you did allow it and gave preference to the alist interpretation, you'd then also have to be very loose about what you called an alist; you wouldn't want to check all the way to the end. So now you've got two levels of ambiguity, which starts to be alarming.
Certainly, it may be possible to give this functionality to lists tagged with the type 'alist. But then what would it do when I want to find the zeroth element of an alist where 0 is a key? You could have it just default to one or the other, but then I'd just end up ignoring whichever indexing operation it doesn't default to and using a differently-named function all the time for the other type of indexing in general alist code. In which case, what's the point of overloading the function in the first place?
No contest, my idea is half-baked. I had in mind symbols as keys, where you could define reasonable semantics. I'm still bugged by the lack of symmetry: For any X with which it makes some sense at all, (X ...) seems to work. Constants, hashes, strings, lists... even lambdas ;-)
Obviously the issue is that alists are only a convention.
