It's not pretty, but it has a consistency to it that includes a lot of compact information in a digestable manner. It takes no longer to decode what the instructions say, but it saves a lot of time parsing, for the human reader of the program.
You can make it even easier on human readers by defining accessors (even if they're just wrappers over car/cdr) and giving them meaningful names. Asking for the car of the car of the cdr of the car of an ad-hoc data structure is pretty hostile toward human readers regardless of whether or not you use caadar.
That's why you actually won't find many instances of such patterns in practice. Either you refactor to have structures/classes, or you define your own accessors. Besides, if you are using CL, FIRST, SECOND, THIRD, ... , TENTH, NTH and REST are defined by the spec (http://clhs.lisp.se/Body/f_firstc.htm).
Are you kidding? cdar would be the second element, cddar the third, and so on. And they're harder to misread on a scan through the code.
As a general rule, I assume that I read most lines of the code not when I'm writing it, nor fixing a bug, but while I'm trying to locate a bug of unknown location. The complexity or trickiness of a function that you are actively modifying can be pretty high and you'll still grasp it. But a function not even involved with a problem needs to be even more legible if you don't want to repeatedly waste time contemplating it to determine if you should move on.
There are first, etc... accessors (other Lisps might define them too, it is so easy to implement). People are encouraged to use them, especially for lists, and are even encouraged to not use them but prefer objects with named slots.
The general advice is to reserve C..R functions for trees, but this is actually rarely needed, especially when using pattern matching.
