I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler.
> A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are capable of, like a full numeric tower (infinite-sized integers, exact rational numbers, imaginary numbers, etc.), record types (like an improved defstruct), CLOS-like OOP, an FFI, composable continuations, a module system, hygienic macros, multiple-value returns, and threads.
Common Lisp has infinite-sized integers, exact rational numbers and imaginary numbers. It has DEFSTRUCT. It has CLOS (obviously). Every Unix Lisp I'm aware of has an FFI. Continuations are actually a problem when it comes to e.g. UNWIND-PROTECT. Common Lisp has packages and an excellent module system in ASDF3. It has hygienic macro libraries, and natively supports the more-powerful DEFMACRO. It supports multiple-value returns. BORDEAUX-THREADS is an excellent portable thread library.
> A third advantage is all Guile APIs/libraries becoming available to Elisp code, no matter what language they’re implemented in, because different languages on the Guile VM can inter-operate quite well, especially if they’re both a Lisp.
Common Lisp has many excellent libraries available via Quicklisp.
Scheme is IMHO a broken language: distinguishing NIL and #f; only have one namespace; continuations; not allowing (cdr nil); not having a native object system; not having a rich type and class library; not having read macros. It was an interesting experiment, but the effort spent on Schemes would have been better spent improving Lisp.
Lisp is far closer to elisp, and is a better language to boot.