Array languages don't just have shorter tokens, they have fewer of them. A small token set is practical because your language's users can only keep a finite number of things in their working memory.
This constraint leads to symbol overloading. But careless, rampant overloading results in the same problem - too many things to remember. So you have to constrain your overloads.
With these constraints, if you want to design a practical, usable, general-purpose language (without forcing users to define every useful thing themselves), you have to choose composable abstractions. Prioritizing a single data structure (arrays) lets you focus your design effort and historically has good mechanical sympathy with the available computers, but there could just as easily be an "APL, but for associative maps" type language.
My point is "good terseness" comes from a holistic design approach, and simply making a bad language more terse will makes its flaws more obvious.
This constraint leads to symbol overloading. But careless, rampant overloading results in the same problem - too many things to remember. So you have to constrain your overloads.
With these constraints, if you want to design a practical, usable, general-purpose language (without forcing users to define every useful thing themselves), you have to choose composable abstractions. Prioritizing a single data structure (arrays) lets you focus your design effort and historically has good mechanical sympathy with the available computers, but there could just as easily be an "APL, but for associative maps" type language.
My point is "good terseness" comes from a holistic design approach, and simply making a bad language more terse will makes its flaws more obvious.