I'm going to argue that there is an objective cost, and that is the length of the code. To me, there's a massive win in being able to take in the whole of an algorithm on a single screen or sheet of paper, and using two statements to do something that can be idiomatically expressed in one is in direct opposition to that. I get the feeling that there are (at least) two camps here that can very easily talk past one another. In my experience, "succinct-code" advocates care about readability just as much as "avoid-language-specific-constructs" advocates. They just have different experiences of what maximally-readable code looks like.
I agree with you there are multiple interpretations, but there’s an important distinction.
For me personally or likely for other experienced engineers, code compactness is a nice thing.
But this is unimportant, because nobody should be writing the code for me or with me in mind. Code compactness for the sake of other experienced engineers is an extremely stupid thing to prioritize above the simplicity of reading straightforward, separated operations that rely on as few concepts as possible.
Code compactness is nowhere near as important as concept compactness, because the latter appeals to all engineers, not merely to other experienced ones.
Anything that requires or introduces a new concept or mixes multiple concepts together is more costly in terms of hurting readability and maintainability than corresponding “longer” code that relies on fewer concepts.
I think I see where you're coming from, although I find it rather dispiriting, in that this point of view seems to be arguing against exploring and understanding the universe of different programming techniques.
It would perhaps be instructive if you could enumerate or point to what you consider to be a good set of concepts to work from. Clearly there are some absurd answers ("it's all NAND gates in the end"), but I don't imagine that's what you're thinking. Would you include functors? applicative functors? Different forms of memory management? APL/R/Numpy-style arrays? setjmp/longjmp?
I don’t see how it argues against exploring and learning about many programming techniques / language specifics / etc. By all means any practicing programmer should be investing to learn about these things.
It’s kind of like martial arts. You are encouraged to learn a huge variety of skills, mostly fundamentals but also esoteric advanced things.
But when it comes to actually using them in real life, you should try to avoid needing to use them at all costs, and even when you are absolutely forced to use the knowledge, use the simplest, most straightforward way to address only the problem at hand, never in excess or for personal interest.
It’s about self-discipline, to orient your code for the mind of an inexperienced novice despite the fact that your simple code might be solving state of the art problems.
