It's just that eval, like goto, is the most general thing in its class. You never want to use either of those when there is a more specific construct that does what you want. Just as we've added various controlled forms of goto over the years, we've looked at the various uses of eval over the years and abstracted out various common operations like aliasing, symbolic references, and closure generation.

As for all the references to optimizations, don't sweat it. It's something language designers and implementors are supposed to worry about, and that concern leaks through at times. But most users shouldn't have to worry about it, at least until they have a bit of code they need to make run faster.

The block form of eval (like your example) can be parsed at compile time along with everything else. I think where the optimizer is going to have to be careful is if you use the string form of eval. In that case, some stuff just won't get optimized that otherwise could be. So the performance-is-vital people will be telling us not to use string eval, and I can safely ignore them if I don't care about optimization :-)