When it comes to typing, there's no advantage to microcode and baked-in type schemes vs byte-addressed but word-aligned machines (ie - pretty much 99% of today's computers). On 32-bit systems you get 3 bits of tag - more than enough for the basic types you need to make a fast runtime. 64-bit gives you 4 tag bits, and if you actually look at any CL compilers today, most of them are unused.
Further, you can exploit various properties of modulo arithmetic over the full pointer to actually produce *faster* code than would be possible with baked-in type checking (see the alignment section in "Arm porting notes and issues" in the Clozure wiki; I'd link but Slashdot box won't let me copy-paste, probably as an anti-spam measure).
As far as GC goes, the biggest problem isn't the hardware, it's the operating system. Look at the Azure Linux kernel patches - they're getting similar GC performance on commodity 64-bit hardware as they did on their custom Java processors with various GC-accelerating features.
You'd be surprised at the number of people working on that (in terms of large-scale "LispM in the cloud" startups, and even new OS efforts). The problem IMO is that Lisp programmers were 15 years late to the Free Software game, and didn't understand the value of portability. The 90s were basically a lost decade for Lisp infrastructure because of that, but I think it's really changed in the past 5 years.
It's amazing how prescient RMS was on the issue. If you didn't know, he started the FSF because he believed Symbolics, the first commercial Lisp machine spinoff from MIT, was going down the wrong path. He was totally validated on everything. If Genera had been open sourced, Symbolics probably would still be a thriving company today.
I think Conrad addresses this criticism effectively in the first few chapters of the book. There's no weird recursive code, and the whole premise is you just download CLISP, get a prompt, and start working (on Debian, apt-get it). That's not any harder than getting Python.
I also don't see how Lisp is not a marketable skill, it's been pretty good at putting bread on my table for a few years now.
I'm the reviewer, so I can probably explain how this happens.
I started out writing posts on my blog about old obscure distributed systems and programming books that I thought deserved more attention. Then I got a copy of Masterminds of Programming for giving a lightning talk at a conference (International Lisp Conference 2007; O'Reilly were giving out books to lightning talkers), and decided to write a review on my blog (it's an interesting book).
A few months later, Peter Seibel's Coders at Work was about to come out, and Peter noticed that I had written about Masterminds and decided that I would be interested in a preview copy of Coders at Work (which I was). Then he mentioned that I should consider writing a review for Coders at Work on Slashdot instead of my blog, and I liked the suggestion, so I wrote a review (it is a good book). Peter says it helped the book's sales a lot.
So the lesson here is you should look for someone interested in the book's subject who has written about other books before, offer to send them a review copy, and suggest they write a review for Slashdot. It helps to stroke their egos ("I really like your writing, would you like a super-special advanced exclusive preview copy for super-smart special people? The proles won't get to see this for another two months!")
Obviously blogs are the best places to find these people; look at blog aggregators on whatever subjects your book is about (for example, the Lisp-related postings on my blog are syndicated on Planet Lisp and Russian Lisp Planet).
O'Reilly has by far the best book promotion efforts of any technical publisher (media relations mailing list, user's group program, and an extremely active presence at conferences), but it's actually not very effective compared to being part of whatever community your book is about, and simply informing community members of your book's existence. Conrad does pretty well in this respect. I'm sure if I hadn't written a review of Land of Lisp for Slashdot, someone else would have.
Do not simplify the design of a program if a way can be found to make it complex and wonderful.