I feel like someone should note the irony of finding this comment on HN, which is implemented in Arc: a language that was explicitly designed to be as terse as possible.
Terseness at different levels. Avoiding boilerplate syntax is good. Obscure abbreviated names of functions and operators just to save a few keystrokes is bad.
Btw. the definition of terseness in the essay seem specifically chosen to favor Lisp style languages.
2 + 3 * 4
is clearly terser than
(+ 2 (* 3 4))
But by counting "leafs" like he does (rather than say tokens), they get the same terseness-count.
I know nothing about programming languages. What makes you predict that, and what makes you feel terseness cannot be a programming language's selling point?
One of the problems with terseness is that it can make code completely unreadable. You can write perfectly readable code with it, but the fact that it's easy to make dense, inscrutable code can make things a nightmare when you're looking at what someone else has made. Especially if that person is a Real Programmer[1].
Of course, a lot of people very much resent the idea of a programming language forcing them to do what they see as pandering to the lowest common denominator (That's what comments are for!). It really is up to the community as to how much description they really need.
Terseness itself tends to confusing and difficult to understand code. Support for extreme terseness formed a large part of the complaints against perl. For examples of powerful languages geared toward terseness, see APL or its derivative J.
http://www.paulgraham.com/arcchallenge.html