I know that. My point is that the antiquated terminology's survival seems to be a symptom of a culture that values the wrong things: like pointless historical names instead of clear modernized ones.
(Monads and props are definitely not better. You won't find me defending them! 'Promise' is a much better name, though.)
Because people like bikeshedding.
Cons is a little bit weird, but it is par with C's "typedef", it could have been named better.
car and cdr are weirder, but there are reasons people use them over first and rest: 1- they are shorter and 2- they can be combined (caadr, cadr, cddr, instead for (first (rest x)) etc).
It is still bikeshedding. You learn that stuff in less time than what it takes to create an angry post.
And if you really hate them, you don't have to use them. Just define a macro and you can stop complaining. Your coworkers may not like this though.
There is actually a good reason: it's precisely because they bring in no semantic baggage. Although conses are usually used to build list structure, they don't have to be used that way; you can make binary trees or even arbitrary graphs with cycles out of them (creating directed cycles requires side effects, of course). The accessors 'first' and 'rest' are appropriate only for conses used as list structure. Even 'left' and 'right', which are less semantically loaded than 'first' and 'rest', wouldn't be appropriate in all cases.
So, what would be a better name than 'cons'? 'List' is not right; the empty list is not a cons. Scheme uses 'pair', which is admittedly not too bad, but I think it would be more appropriate for an immutable pair than a mutable two-element struct. (I actually think there should be two types, immutable pairs and mutable conses. In such a Lisp, conses would probably be fairly rarely used, and much more of a historical relic.)
And to echo what outworlder says, it really just isn't that big a deal. Yes, Common Lisp has some historical baggage, and a lot of things we would change if were designing our own Lisp from scratch — I assure you every Lisper has their own list. But CL rationalization projects, of which there have been several over the years (and, no doubt, more that I'm not aware of), don't catch on. The reason is clear: the CL community is already "small yet remarkably fragmented" as I recall someone putting it (Eric Raymond?); a rationalized CL would just fork off another sub-community, if it caught on at all.
Sometimes in CS education Lisp is/was used to teach new stuff, making sure that students were challenged beyond their comfort zones, for example by reinventing the basic machineries from a few abstract principles. Typically Lisp was not used as a programming language, but as a device to teach new ways to think about computation: algorithms, some basic data structures, control structures, functional programming, ... Today you'll see other langages in CS education, with other goals.
(Monads and props are definitely not better. You won't find me defending them! 'Promise' is a much better name, though.)