You're really misrepresenting Lisp macros here, being able to rewrite syntax is only one (admittedly important) facet of these.
The real thing with CL is that the entire language is available during parsing and macro expansion and that users can hook into these steps to influence them. No artificial limitations like you get in C++'s consteval, you can do everything and anything without having to use a crappy DSL to do it.
Also, I've never found SBCL slow to compile. Have you?
(1) SBCL is fine in terms of speed so far as I am concerned. But wherever you have software engineering in the large, especially involving C++, you have 40 minute builds and a split between smart people who think that's a problem and smart people who don't.
(2) The trouble with those balls-to-the-walls macros is that systems that use them tend to be "write only", like some guy writes 4000 lines of Lisp that do the work of 80,000 lines of C++ and then he moves on and there is never a version 2.0 but the system gets rewritten in C++, supposedly for performance, but really because they couldn't find anybody who could maintain it. It is really pleasing to see how little code is in Lisp systems from the golden age of AI but... when Yahoo! bought Graham's startup they kept the customers but threw away the code.
You are more likely to be sustainable if you get two people to write 12,000 lines in something like typescript or ML that uses Dragon Book technology to the same end.