The only real argument against using eval, IIRC is this:
Eval executes arbitrary code supplied at runtime, while
most programmers want to execute some flexible structure with defined limits that language can't express at compile-time.
i.e. use of eval is a cludge to bypass programmers inability to express dynamic code structures at compile-time, leading to arbitrary runtime data from users to execute/interpret something.
Interpretation of executable data is the only valid use for eval, and its likely also a cludge - since the language optimal for interpretation of data has different purposes from compiled languages:LISP DSL used for turning data to code is suboptimal vs actual language that is optimized for specific cases(i.e. a separate optimizing compiler, XML parser,JavaScript interpreter).
Trying to fit everything into LISP because its capable of interpreting everything with sufficient abstraction is some kind of anti-pattern,like tying everything into OOP paradigm:
LISP DSL constructs are not equivalent to imperative/algorithmic code, like a combination of lego blocks is not equivalent to a monolithic plastic structure with embedded metal parts.
The problem here is that LISP constructs obscure the costs of
computation when they are composed, giving the impression of elegance at expense of internal ugliness of implementation:
the C code produced by Scheme-to-C compilers illustrates this well
and provides hints why LISP optimization has limits.