Because eval evaluates its argument in the null lexical environment.The environment can be captured to an environment object by a macro then to be passed to another macro but the environment object is implementation-dependent so you can't easily build lexical environment from that.

Do you know why it prints 666 instead of 14? The reason is the same as why your code acts the way it does (but note that it doesn't have to...what you've written is not strictly legal in Common Lisp; in my implementation it sets www to 14, and (try) prints 14. Why? Because (setf z 666) doesn't have any meaning when z doesn't exist -- you need a DEFVAR or DEFPARAMETER, or a LET or something, to make a variable called z before you can say (setf z 666), and you haven't got one.)

Eval can be useful if you want to write your own repl or interpreter. But in 99% of the cases where beginners tend to use eval there is a better solution using functional objects and funcall. It also executes much faster than eval.

the result of the last "let" construction is 667 but not 14 as expected. My question: is there any clever way to "execute" the variable COMMAND inside "let" constiruction so that this execution uses the current value of variable "A" which is 13?

(list 'lambda () command) returns a lambda-expression not a evaluated lambda-expression so this won't work in many CL-implementations.As mentioned before; If you declare a dynamically scoped it will do what you want.