jesnell
(Edit: Oh, but the place where it's hooked into also is bypassing some compiler passes that might turn out to be too fundamental, like representation selection which decides whether values should be stored tagged or as raw machine values. One theory is that some of LLVM's more advanced or future optimizations will obviate the need for that pass. The other is that really LLVM should work at the same level as other SBCL backends, after all the generic low level decisions have been made. This work is still at such an early stage that we haven't even figured out which of the two theories is true.)
But of course that's not of much interest to the average user. I think SBCL is in general faster, is developed more actively, has more features that are relevant in the modern world (eg. lose a Motif interface, gain native threads), and currently runs on more platforms than CMUCL does.
My impression is that most people using CMUCL are ones who started using it 10 years ago and are comfortable with it, new users would tend to go with SBCL. But I'm biased, so it's quite possible that there are real and substantial reasons to prefer CMUCL.