It is homoiconic without parenthesis soup. It also supports removing commands to the point of being non-Turing complete. That makes it useful as a configuration language for non-trusted input that can be extended as needed.
I've been writing a lot of lisp lately, and I don't know that homoiconicity is in and of itself a virtue. It's nice to have, I suppose, but I don't see what it really brings to the table other than a time-saving hack for reading configuration from disk.
I don't think homoiconicity itself is the most important thing. I think the real power of Lisp comes from a bunch of other features, and a non-homoiconic language would be approximately equal in power to Lisp if it had these features:
1) A public API for manipulating the AST in the standard library. Most languages have some AST API defined as internals of their compiler/interpreter, but it is a private API, not a public API in their standard library. (Lisp's AST is almost trivial; but a language could have some kind of complex ADT-based or object-oriented AST and it would still be okay, so long as the AST is a public API in the standard library.)
2) The AST should be extensible, so you can define new types of nodes.
3) Ability to write arbitrary code (compile-time macros) which gets executed at compile time, and which can read the AST, and generate a replacement AST.
4) Compile-time macros are written in the same language (or almost the same language) as runtime code, rather than some special language (compare the C preprocessor to C).
5) Some form of syntax extensibility
6) Code to execute at compile-time, new AST node types, syntax extensions, etc, can be defined in the same program which uses them, as opposed to being segregated to some kind of "compiler plugin" with some kind of special build process
7) Some kind of "quotation syntax", where you write some code, and instead of actually being compiled, instead code to generate its AST is compiled. For example, 1+1 might evaluate to 2, %ast(1+1) (to pick a possible syntax at random) might evaluate to the AST for 1+1.
8) Some kind of "backquote syntax", to make it easy to write code templates (this is basically just (6) with ability to make substitutions in a hygenic way).
9) All of the above should be able to expressed with syntactic succinctness. Don't be afraid to add special syntax, or even some embedded DSLs, if it makes the above easier to express. (For the language designer/implementor, much of this may simply be dogfooding point 5 above.)
Now, homoiconicity means Lisp can give you (1)-(9) with less work (for the language implementor) than a non-homoiconic language might require. But not everyone likes the simplistic syntaxes which homoiconic languages tend to have, and there is no reason why a language with an Algol-like or C-like or Pascal-like syntax couldn't give you (1)-(9) as well, albeit with a bit more work. Indeed, if you took any existing language and added (1)–(9) to it (if any of them weren't already there), and made sure to do it in an easy to use way, you'd basically end up with a language roughly equivalent to Lisp in power.
