The shortest way to conditional insert properties into an object literal

I completely disagree because lot of JS syntax and features need an explaination. Think about coercion, generators, arrow functions, async await, the asynchronous iteration, proxies, ecc.
More generally each concept in every programming language, also the basic ones, may need an explanation.

And, with your line of thinking, people risk to never learn anything and never improve themselves.

The article is explaining why the syntax is valid. But the main concept, the optional insertion of a property, is understandable in 10 seconds.
After a little example, if you spend 5 mins with it, you can already understand what's going on:

...condition && {prop:value}

If the condition is true a prop will be added. No side effects in the other case. Simple.

It's something with which one can become familiar in no time, it's something immediately teachable to others and I've demostrated that it works not because an undefined, untrustable behaviour but thanks to a precise logic put black on white in the spec.

This is referred to as the "either/or fallacy", also referred to as the "false dilemma": en.wikipedia.org/wiki/False_dilemma

This is a perfectly self-explanatory technique. If you understand the spread syntax, and how short-circuted Boolean expressions work, then you can see at a glance what this does. The text above is not an explanation of the code, but proof that it works without surprises. Hence, this is both the shortest and quite self-explanatory.

I would even go so far as to say that this is a lot more readable than the alternatives. Bravo, Mr. Costa.

At no point does the author claim that short code should supersede readable code.

I like this pattern not just because it's the "shortest" but because it's the most declarative. This way, I can construct and assign my object in one place, without going back later to mutate it's contents. I think that leads to better code because it reduces the need to mentally execute each line.

It's called an "idiom". Like any other idiom, including idioms in naturally language, you have to learn it. That doesn't mean it's not useful. If people run into it and are not familiar with it, they'll figure it out quickly and then know it themselves.

Just make sure to internalize what JavaScript considers truthy and you won't think this is a "gotcha" anymore.

So in your specific case you'd probably want to do something like

const coins = 0;
const obj = {
  name: "John",
  ...typeof coins === "number" && !isNaN(coins) && {coins},
};

So there is no point to use the trick in this way if 0 is a valid amount as well.

Remember that on the left you put the condition, so you may write like the following:

𝐯𝐚𝐫 𝐜𝐨𝐢𝐧𝐬 = 𝟎;
𝐯𝐚𝐫 𝐨𝐛𝐣 = {
  𝐧𝐚𝐦𝐞: "𝐉𝐨𝐡𝐧",
  ...𝐜𝐨𝐢𝐧𝐬>=0 && { 𝐜𝐨𝐢𝐧𝐬𝐀𝐦𝐨𝐮𝐧𝐭: 𝐜𝐨𝐢𝐧𝐬 }
}

you could pass coins to a method that checks for false, null, and undefined only (or something along those lines)

To me, more terse code is almost always easier to parse. Of course, everyone's different. There's not really a one size fits all solution. You'll have to agree with your team on a working standard.

I've already expressed mine opinion here around, and to be technically precise the code is easily testable as any if construct.
Thanks for sharing your opinion!

I think you will understand that this is beyond the scope of the article.
My first point was to show a nice, little know js fact. The second was to explain why such code is allowed.
All the rest is left to the reader's good will and curiosity :D

In the case of Firebase, to take one example, a value of undefined is treated differently than a missing property, and causes an error.

I do love find alternative ways to do common things 😆, I'm honored to have opened your mind 😝

Very helpful what Stan posted here. Parenthesis really help. Actually they are a default lint recommendation in this specific case. I think adding them to the code in the article would help a lot.

Thank you!

You're welcome!

Google rest/spread operators 😆