>>5
The braces can also help set apart lisp's eval as a side effect, for lisp it's self and the implementer, not the programmer reading the code. A lost improvement that thinks more about how the language gets implemented instead of blindly ignoring it and hoping someone is masochist enough to work on compiler toolchains and things like mixing lalr with irrgex.
There's also the freely bendable macros but I'm sure anons here understand at minimal lisp macros aren't unruly, the eval being text vs all encompassing makes sense and is easy to forget even if using multiple different languages that have a concept of eval with varying symbology.
Since there's other languages that support such types of macros and symbolic eval, it's about the entirety of lisp and the time frame it was created. There's a downside to most of this, like the constant braces which can tick a reader off or understanding what can truly happen when you blindly eval something you generated with complex multiple function macros.