I'd argue truthiness implicated by the presence of an object is more logical than having an arbitrary definition of truthiness depending on the data type.

If I have a cup that's empty, there's still a cup there. It's presumptuous to assume I care about the contents.

There's a presumption either way. You can make the presumption JS did for [] (and there's probably no turning back), you can even argue explicit is better than implicit (vs the value of context-sensitive concision).

But it's also not consistent with the ways that other empty but typed cups are treated ("" for the empty string, 0 for empty count / quantity, both of which are false-y). Different presumptions for different types of cups carries its own implicit hazards from context sensitivity.

In that case "" should be truthy. And 0 should be truthy too probably.

They should be, to have consistency in design. Note that if the language operated this way, checks on these types would be more explicit (though more verbose too).

Checking for presence of a number with a truthy check is a common source of errors, if 0 is a valid number.

I just don't agree at all that Python's interpretation of truthiness (or equality, for that matter) is inherently the "right" one. If I clone somebody are they equal because they have the same genetic makeup? No. Though a pretty contrived example that requires common understanding of equality.

At least from a programming perspective, I usually care more about instance equality rather than structural equality. Of course Python supports that too via the `is` keyword

Yes and yes. Ruby got it right, no question :)