Simplicity is undervalued quality. It's far simpler from the point of view of dependency management, that if one is developing a large codebase in C++, to also have the scripting language be native to that environment, rather than to first create a DLL of the C++ codebase, then implement the FFI to it using e.g. SWIG, PINVOKE, or such, to call the C++ context from one of these "premade DLL" substrates.
It's fairly trivial to expose C++ libraries to any other language context, IFF the library is wrapped to a DLL that respects the C ABI. The reverse is not true. You need to have some message passing mechanism in that case (yes, there are several not-so-hard ways to do that but that again, is added complexity).
Yes, and building a library (a DSL) in an existing powerful language that can do it (and there are many as people said in this thread) for exactly what you need, is _vastly_ simpler than making a new language toolchain (which linker? which codegen? which typing?).
I agree - choose the best tool for the job. As a counterpoint - Implementing an interpeted macro-less lisp is a few thousands of lines of code in C or C++. So if the goal is just to bootstrap some language, the effort is more about typing than design or innovation (just copy the interpreter in chapter 4.1 of Structure and interpretation of computer programs).
A stack based language like forth would be even less work.
It's fairly trivial to expose C++ libraries to any other language context, IFF the library is wrapped to a DLL that respects the C ABI. The reverse is not true. You need to have some message passing mechanism in that case (yes, there are several not-so-hard ways to do that but that again, is added complexity).