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.

Don't know anything about Arc, but is there is anything terser than APL?

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.

[1]https://www.cs.utah.edu/~elb/folklore/mel.html

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.

I would offer that terseness is not a substantial goal because it can be achieved in too many terrible ways.