I’ve also written a Lisp on top of elixir, lisp is dead-simple to create. But how about this for an example of it’s power:
First, Elixir has an AST, you cannot create or invent new forms, you can only make function-like things and parse already ‘formed’ expressions within those calls. Second, in Elixir you can parse a string at compile time (which is what I do with my elixir lisp), but the string is delimited, thankfully Elixir has a way around it by using things like ~L{lispy code} or so, but if you end up using } anywhere in the string then it dies, same regardless of the identifiers you use.
In comparison, I’ll use my elixir lisp as an example since it is more Elixir’y than normal lisp, there is no real form, there are just lists and symbols. A list is delimited by (/) (unless escaped via \), and everything else is a symbol, separated by whitespace (again, unless escaped). So if you want to define a number just doing 42 will not work, you’ve gotta do (integer 42) for example, or (atom blah) or (list a (integer 42) (float 6.28)) or (string This\ is\ a\ string), nasty painful and such. So you can simplify some things via macro’s, so like the above list one you could write a macro so you could just do something like (mymacro blah 42 6.28) and it expands it to the above list. However that is just like defining new functions, just like you can do in elixir, it is not really making new syntax, for that you need read-macro’s, which my lisp also supports in spades. I have a few built-in read-macro’s, like one triggers on : at the start of an expression, it then parses the next symbol (or fails if a list) and just wraps it in the (atom ...) list. I have one that reads based on " and reads characters until it hits an unescaped " (it supports a few other escapes as well) then just wraps that all up as a (string ...) as a single symbol. I have one that starts with a [ and reads sexpr’s until it hits a matching unescaped ] (since it reads sexpr’s it recurses back into the parser so you can have embedded [ no problem as one example) and wraps that up in the (list ...). And one that reads a { and is like list but wraps it up in (tuple ...). And one for %{ that wraps it up in a (map ...). I could actually quite easily (and it is planned) to make some kind of elixir read-macro that then passes the stream to the elixir parser to get the elixir ast back (essentially an elixir quote). The ‘magic’ of Lisp is that you can make domain specific languages for any problem you could possibly ever experience, able to add any functionality that any other language has or could ever have, and thanks to it’s macros and read-macro’s both then it can be as succinct and readable (even parenthesis-less if you really want) as you can imagine. You can embed Elixir in lisp, or python in lisp, and it all just compiles down to lisp.
Lisp itself is not so much a language to write programs in, but rather it is a language to write languages in which to write programs. 
And yes, Lisp is one of those languages you should definitely learn and keep learning until you finally get that *click* moment when everything becomes clear about why it is used, and I’m not just talking about treating code as data and data as code, I mean the way you can define any problem in it in a way that is natural to that problem.
