> Then there is the contrarian in me that is probably just getting annoyed that they labeled the proposal as the "improved" piece of code. :D
Well, we think it's improved. Of course, what matters is "how you measure improvement" :-). Like anything else in engineering, there are always trade-offs, and you have to figure out what you value in the trade.
That said, here are a few ways I'd argue it is better:
1. It uses standard infix notation, instead of non-standard prefix notation. The standard worldwide notation for mathematics uses infix, as do practically all programming languages. That means practically all math books use infix, and most adults have over a decade of training in infix. The majority of programmers are never going to switch to a language that doesn't support infix notation.
2. Similarly, it uses a more-standard notation for function calls, e.g., "factorial(n)" instead of "(factorial n)". I don't think that's as big a deal, but it helps. It doesn't use "," for parameter separation (it could, but the extra commas are unnecessary and dangerously hide other uses of ",").
3. You don't need to figure out "did I match all the parens" when reading the code - instead, the visual layout tells you everything. Many developers don't like all the parens and find them to be an impediment to understanding (Google "Lots of Irritating Silly Parentheses"). If you don't like the whitespace layout, fine, you can use n-expressions instead of sweet-expressions.
The broad impact of these changes is that these notations retain all of Lisp's power (macros, quasiquoting, etc.), but look much more like a modern programming language. That matters, because software development today is normally done in groups - anything that makes code harder to read is a serious problem.