There are quite a few Scheme implementations, and Racket isn't necessarily the obvious choice. However, it does surprise me to see a reimplementation rather than using at least one of the existing implementations.
Well, I mention Racket because it has extensive tooling for new language creation (I've seen C-like, Java-like, and SQL-like languages implemented in it), and they've done so much work in creating a very extensive standard library that compiles and optimizes down to relatively simple Scheme base language. You basically get tools and libraries and optimizations and other languages "for free" if you use Racket, much like with the CLR, but in a completely open-source, could-be-statically-compiled-if-you-want way.
I can think of some reasons you might not want to build it on Racket. I think Racket is fantastic, but if you are developing some novel variety of Scheme or whatever then you might want to have control over "low level" (I'm sorry, I dislike that term) details like how closures get allocated or the evaluation order of things. It's perfectly cool to use Racket to write the implementation of such things though, but maybe as a more traditional language implementation. Of course you're right that it's much smarter to let other people solve the problems you don't care about, so most of the time Racket would be a sensible platform to build on top of.
Maybe you don't want to get all those features for free. Maybe you want the opposite: to not have those features at all.
If you are going to build a Lisp processor, then you probably don't want a Lisp compiler or interpreter in the traditional sense, which is what Racket gives you. Maybe what you want is an interpreter in hardware.