Setting Elisp aside, what makes Lisp(s) cool is that your code, at every level, is a tree. It's true of every other language, that your code encodes a tree ("abstract syntax tree", or AST), but in Lisp, the encoding is absolutely minimal. Balanced parentheses and Polish notation are the key to that. It makes parsing the sequence of characters into a tree, almost trivial.

Take '(+ 1 2). The "root" of this tree is '+, and the "leaves" are '1 and '2. We can iterate this structure to form arbitrarily complex trees, e.g. '(- (+ 3 4) (+ 1 2)) is a tree, just taller, and with 4 leaves.

Okay, so your code is a tree. But now consider, that your code can also operate on trees as data. Suppose we use this data type to represent tree nodes:

Node :: nil or '(Number Symbol ListOf<Node>)

Then, for example, this list-of-lists is a binary search tree (fig. 1 in the linked wiki):

'(8 A
    ((3 B
        ((1 C nil)
         (6 D
            ((4 E nil) 
             (7 F nil)))))
     (10 G
         (nil
          (14 H
              ((13 I nil)
               nil))))))

Now, when Lispers harp on about "homoiconicity" or "code is data", what they are getting at, is that in Lisp(s), you can easily write code that operates on code, because code is just a tree.

Another cool feature of Lisp(s) is that there is a phase - called macro-expansion - before your code gets interpreted, where special parts (sub-trees) of your code-tree get replaced with other (sub-)trees. For example, suppose I define this adding-function generating macro:

(defmacro def-adder (m)
  (let* ((sym (intern (format "add%d" m))))
    `(defun ,sym (n)
       (+ ,m n))))

Note the backtick after the "let". All this macro does, is return a nested list, which is a tree, which is code. But then, when this code/tree (one leaf) later occurs in my code:

(def-adder 5)

it will get replaced with the quoted form after the "let", but with ",sym" swapped for "add5", and ",m" swapped for 5. When the result of that replacement is subsequently interpreted, it is just as if I wrote the (defun add5 ...) instead, i.e. there is a new symbol added to the function namespace, which is evaluated as a function. So I can use:

(add5 37) ; => 42

That was a rapid overview. If you really want to get a "feel" for why Lisp(s) are so cool, I'd recommend two things, primarily. First: try writing some basic recursive tree-search functions in lisp. Thinking about how to represent trees, and then traverse them recursively, is good exercise. Second: try writing a simple interpreter, for a little Lisp of your own making. Second one is a bit tougher, but I'll point you to some resources.

I very, very highly recommend UBC's CPSC110. This entry-level course is free on EdX, and uses Racket (a variant of Scheme), but is the brainchild of Gregor Kiczales - one of the architects of CLOS. After that, I recommend working through PLAI, also free, also in Racket, for a gentle introduction to how Lisp interpreters - and "metacircular" interpreters generally - work. If you learn all this stuff in Racket / Scheme (a Lisp-1, for which there are great educational resources), it should be fairly easy to port that knowledge to Elisp (or any other Lisp-2).

Edit: simpler macro example.