Clarity, not brevity is the thing that should be put on a pedestal. Brief code isn’t necessarily clearer code. Sometimes a terse line of code needs to be split over several lines so that the engineer can clearly see what’s happening. Based on your view though, this is bad because there is more code to “break”. I disagree.
That said while I agree with the spirit of your argument, but you misinterpreted Wil Shipley’s blog. He was talking about adding unnecessary complexity and functionality before it was really needed, not using the most concise representations available to the language.