To use an analogy, you are suggesting to use mathematical tables ( https://en.wikipedia.org/wiki/Mathematical_table ) instead of algorithms to calculate functions (for example, approximating by Taylor series) because algorithms are hard to read.

It can work in some cases (lookup-table based functions in microprocessors), but does not make the contrary approach an anti-pattern.

The mini-framework is what divides the problem into an abstract and concrete part, where concrete part can become purely declarative code even.

I am not endorsing highly-parametrized functions you are using as an example, just trying to say, that when one has dozens of similar functions, it may be good time to refactor the solution with mini-framework to jump to the next level of abstraction.

Then probably you will not need to chase SQL-injections in dozens of classes because probably those SQLs will not be in the code directly (like in ORMs).

It may also be, that I have not fully understood what you mean by code-in-code pattern, but it has not been quite defined in the article. Patterns / anti-patterns definitions (in the books and research articles, which list them) are described using standardized approach (eg, context, problem, solution), where system of forces is involved. Without that "anti-pattern" is just a now fashionable way to say "I do not like this way to code".

I would be much harder to dismiss your finding if it were described like other software engineering anti-patterns.