I inherited a build system that is based on using a multibranch pipeline with a Jenkinsfile that loads and executes a groovy script that's generated on the fly based on input from structured data from json files found alongside the Jenkinsfile in the repo. So, yeah, it's basically a hand-rolled solution to parametrizing a job. It sounds like that's basically what you're trying to accomplish as well, Jeff.
The part I don't like is the way we're generating the groovy code. We've a library of python code that uses classes and a streaming approach to outputting all the syntax required to implement the pipeline. First of all, there's a high learning curve to using this approach - when trying to determine what the groovy output will look like you have to run the code and look at the output, which is a whole software development process in and of itself. When making changes, instead of using a template with variable substitution and loops perhaps, with the programatic approach, you have to write (and test and debug) code to make the groovy code you want. A template already resembles what the final output (groovy) will look like, so it's quite intuitive to work on. Also, every time you need to use a new groovy construct, with the programatic approach, you have to add support for it in your code gen library. With the template you just write it, based on the pipeline syntax documents. This brings up another reason why templated approach is superior: Programatic approach obfuscates the details of the language from the code gen developer. Looking back and forth between the jenkins pipeline syntax docs and a template is straightforward, not so with a library of classes defined to generate groovy.
So, that's my $0.02. I plan to refactor our code gen library to use jinja2 templating to make our pipelines more intuitive and easier to work with.
Another thing related to keep in mind is that, as far as I can tell, the "load" command, which is the mechanism you would use to actually run your generated pipeline script, is designed to work with Scripted Pipeline, not Declarative. This distinction is very poorly documented by Cloudbees, IMO. Please chime in if you have more info on dynamic generation and running of pipeline code.