Well, let me see, efficiency, a ram smaller than 4GB, power.
There have been embedded Lisps that used less than 48KB of RAM total. There's some modern implementations aimed at such limits, but they barely interest me as I do have 4GB of RAM and a fast CPU, and so do all my boxes that I'm going to run my software on, however in practice the Lisp image would be using between 10-30mb of RAM, and then fluctuate up and down by a few dozen MB as the application conses and gets gc'ed. You can actually write apps that cons little or not at all, but lets be fair and say that most Lisp programmers won't write such things unless they either hit a performance wall or just need to microoptimize everything from the start (in which case they might as well be using C if they're planning to specify every little detail anyway).
You don't need to cache anything, the compiler can use memoization, at least C compilers do.
Many Lisp compilers can do memoization, but if you don't trust your compiler or want to do your own? It's only a few extra characters(locally cache something at readtime) to a few lines of code to implement such a mechanism (full memoization at runtime). In Lisp, implementing all kinds of (front-end) optimizations you might want your compiler to implement is easy, and people do it all the time because of that. (Back-end optimizations are just as doable, but the implementation would no longer be portable in most cases as it depends on a specific backend...) These can all be expressed in terms of cons cells and atoms.
Sure, but it's a waste of memory to only use cons cells. Any serious Lisp implementation tends to just use arrays and structures(memory layout) to implement more complex objects. A cons cell is just a structure with 2 elements. If you're not going to waste time trying to change something about my opinion then it makes me wonder why you argue with me.
You showed you don't know Lisp very well in the previous examples, that nullified any interest in me arguing with you. Why would I argue about things someone doesn't fully understand? I would be fine arguing with someone who knows Lisp inside-out. Such a person can actually make valid arguments about things to dislike or that might need fixing in Lisp. Your problems are not actual issues to any real Lisp programmer. The only reason I'm arguing with you is not to change your opinion since you seem dead-set on thinking that Lisp isn't for you, but to make sure you don't misinform other readers of /prog/.
380 bytes more than needed is not "much"? You sound like a spoiled brat, and what spoiled you is moma-industry with its Moores law.
It's plenty, but it's very very little for most modern hardware. Not only that, while the case I gave doesn't need this at all, but a real use of FORMAT might need to use that memory.