Happened to me a month ago. There was in fact a lot of information on the net on how to fix it, but none of the suggestions worked. In the end only a full reinstall of OS X (done for unrelated reasons) fixed it for me.
SBCL's low level code generation is total crap, the smart bits are in the high level optimizations. (And to be honest, even those smart bits are fundamentally 80s technology, it's just that most dynamic language implementations never got even that far up the technology ladder). What James is doing is hooking LLVM in after most of those high level optimizations have been done, but letting LLVM worry about instruction selection, instruction reordering, register allocation, etc.
(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.)
SBCL set out to make a version of CMUCL that was easier to build and maintain. I'm pretty sure that was delivered.
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.