Author here, and I agree that using templates for complex code generation is a mess. However, it's a popular mess in some branches of high performance computing right now, especially for dealing with the transition to execution on GPUs. If you're stuck in C++ and want abstraction without runtime cost, templates are what you've got. An alternative option is to step outside of C++ and write a compiler or source-to-source translator in a more suitable language (the direction we've gone since), but that means existing C++ programs can't just drop in your DSL as a library without adding more bits to their toolchain.

If you do decide to make a complex library based on template meta-programming, you inevitably end up needing a meta-meta language to help build it because templates are so ill-suited to the task (especially before C++ 11). Many template-based libraries (like Eigen, http://eigen.tuxfamily.org/) have chosen to use preprocessor macros as that meta-meta language; we decided Racket was a better choice and this paper is our exploration of how that might work. I suppose an interesting takeaway is that even if user constraints force you to implement your DSL compiler as a template meta-program, you can still use an outside meta-meta language to help create the templates.

The statements regarding debuggability make two claims that I think are correct, if not particularly strong: 1. using Fulmar as a meta-meta language produces a more readable template meta-program to examine than do preprocessor macros; 2. Fulmar can catch some errors at the meta-meta level and provide nice errors (section 4.5) in places you might have otherwise received the nasty template expansion errors (again unlike preprocessor macros).