Maybe people have an easier time understanding other languages because they work in the same way the computer does.
you don't need to know what your lisp gets turned into. you do need to know something about what tree your lisp, or infix math, or chained C functions, get turned into. you have to actually know which tokens go into which branches. you have to know what functions are being called on what tokens, in what order.
Personally, I find Lisp easier to write but much harder to read. The syntax certainly plays some role in that, but I don't think it's the key. The problem, I think, is that it's just too dense. When you use a lot of intermediate variables, you get to name them something relevant. But Lisp code (or at least my Lisp code) usually doesn't have all of this context floating around, so it's harder to figure out what's going on.
It's quite possible that the prevalent style of writing Lisp code is in some ways worse than the dominant style for C/java/etc. But that is a different issue than the language itself, which can, for example, create a bunch of name intermediate variables, if you want them.
The flexibility of Lisp probably makes it more suited to adapting to encourage naming data, over imperative languages encouraging MSFs. let/let* is a little clunky for simple things -- it reminds me a little of Pascal's variable declaration blocks. It would be better to do a sort of: (lambda (a b) (A <- foo a) (B <- bar A b) (Z <- baz B) Z) or optionally (return Z) instead of just Z, which macros to (lambda (a b) (baz (bar (foo a) b))))
It seems like the sort of thing that someone would already have implemented, but I don't recall it being a core feature anywhere.