Racket takes an interesting approach with its scoped dialects. This allows the semblance (and some of the semantics) of separate implementations, while still preserving the interoperability.
 I have one project which uses libraries written in the base, typed, and lazy dialects all together, without any issue.
Which, because I never learned anything about Lisps in school, was that I just wanted to become familiar with it. I looked hard at CL and, when it looked straight back at me and I felt it's ancient, powerful gaze upon me, I quickly ran off to schemeland. Where, of course, I hit the multi-implementations-wall immediately. I didn't want to learn a "toy" (as in "here, have a language - now go and implement all the libraries you need from scratch or by wrapping C calls") language and I wanted to solve real-world problems with my first Lisp, so I naturally looked for "the best" implementation: most library rich, best documented and actively developed and used.
I chose Racket and I'm very happy I did. Not only I learned about Lisp beauty and power while building small, but useful and fun things, I ended up in an environment that makes me improve my skills every time I go back to the language and probably will continue to do so in the future - even when I will finally learn all of the base (not racket/base - racket) language I will just transition smoothly to learning other languages and then to creating my own.
As an effect I don't know Scheme at all, which is makes me feel like I missed something. I know and use several SRFIs, but only when Racket does not provide alternatives, which happens rarely. I have no idea what is written in R6RS and I don't follow R7RS. Heck, I probably don't even know what Scheme is all about! On the other hand, though, I now know (somewhat) a Lisp and a powerful, batteries included, practical language and an experimental academic beast in one.
Anyway, don't use Racket if what you want is just a Scheme. [EDIT: or for embedding. Or producing native binaries (if I understand correctly 'raco exe' mentioned in the article works like py2exe rather than like "real" native compilation... I can be wrong, never used it). Or for anything that Racket is not suitable for ;), but] for everything else I can only recommend it.
(Don't mention Clojure in response to this comment, please. I'm somewhat allergic to it, it's not Clojure fault, it's mine, Clojure is good, really brilliant, very interesting. I'd like to like it, but I don't, sorry... So no, don't ask me 'have I tried Clojure' :) )
If I remember correctly breaking with this image was one of the reasons for name switch, but it was done rather recently (in 2010) and it will take some more time before Racket will get it's chance in the real world... Just how many years it took Haskell to convince people that it's something more than an obscure research project?
Certainly, the language would benefit greatly from much higher number of libraries, for example, and their lack can be a serious setback for larger projects. On the other hand the language itself includes many sophisticated, impressive features that help with programming such projects - one tiny example is a very nice module system, closer in essence (I think) to that of OCaml than to that of Python and another is an object system, which is well thought out, easy to use and really powerful.
So, while Racket is nowhere near Common Lisp (I really hope you used 'CL' as abbreviation for Common List and not Clojure :)) in industrial usage, I believe that it is (or will be shortly) ready for it's chance in the real world. It would take one or two moderately successful startups to build their products in Racket and open-source all the libraries they wrote to make Racket really viable alternative for other languages.