From my experience, I have seem many cases where the "let's help api users/client code developpers save some keystrokes" mentality has brought a lot of issues.
Not sure if related to the question though, but still I think shorter is better only applies as one of the principles, among "explicit is better than implicit", "do not try to guess" and "code is read ten times more often than written".
Another example would be the hello world one liners. Some languages are very proud to have a hello world in 11 characters, but if just because of the hello world you add a new special grammar like "print to screen what is between curlies if not inside another token", then you are doing it wrong.
The shorter the code, the less room there is for bugs to hide. There are exceptions to that rule but they are not nearly as common as people make them out to be.
It still seems hard to beat the size of the parse tree as a test. (Characters would not be as good a test.)