Did you not read the talk? You can provide the car/cdr interface on top of tree-based implementations. Yes, you pay a cost to use that interface...but you pay a different (Guy Steele would argue more expensive) cost if you write your algorithms using car/cdr instead of, say, empty/singleton/conc.
Moreover, as is pointed out on the slides, a lot of processing can happen without ever having to talk about car/cdr, e.g., using higher-order functions like map and filter.
This aspect of the talk is a big justification for more abstraction in a lisp (namely interfaces / type classes / similar).
This decision should not actually affect written code, other than maybe a type declaration or similar to say "this is a singly linked list" or "this is a tree list". Even if you ignore performance, that car really means "get the first element of this two element cons cell" rather than "get the first element of this sequence" is one of the most obvious limitations / warts of (classical) lisp (and scheme) as compared to more modern languages designed with data abstraction in mind.
Of course, this is "modern" as in OO decades ago (Java, C++, etc). Taking it a step further you could omit the type declaration entirely and infer at compile or runtime (via profiling + JIT) which list implementation is best.
Moreover, as is pointed out on the slides, a lot of processing can happen without ever having to talk about car/cdr, e.g., using higher-order functions like map and filter.