The question was because, to me, "get own property returned empty" means that such a property does not exist on the object. Hence asserting it right after seemed redundant, and made me think that maybe there's a deeper meaning here.

From an implementation standpoint, we've been adding asserts into our engine code as either debug or runtime checks for now, to make sure we're correct. engine262 doesn't write the assert in this case at all (maybe it never does?), and a few other engines likewise skip the assert. Others do check that the property storage indeed does not have this property.

For our engine such a check is mildly problematic, as how a given property might be stored depends on the object type and even on its usage. That logic is of course all encoded in the internal methods. So I wondered if skipping this check was ... I don't know, the spec somehow asserting a need to know about object property stores or how they work or something.

to me, "get own property returned empty" means that such a property does not exist on the object

This is a thing you know only after becoming familiar with the language and the specification. There's no intrinsic reason this would have to be true of an arbitrary operation called [[GetOwnProperty]]; rather, it's something which we arrange to be true, and the point of the assert is to point it out to the reader who may not be already be familiar with the language and specification.