The value of an embedded object is in editorial usability and repository management, since the editorial element will often be an embedded object creation interface specifically for the embedded type. This “sub-interface” might be a modal dialog, collapsible pane, or simple appear as a section inside the main editing interface.
Some editing interfaces might get complicated as the embedded object might be of a type with a very complicated interface itself – in theory, the editing interface of the embedded type could be more complicated than the interface of the owning type.
And what if the embedded object type also has attributes which are embedded objects? What if one of those typed attributes requires a type of the owning object… which also requires a value of the embedded type? Could we have an infinitely nested interface?
If the embedded object’s UI isn’t part of the owner object’s UI, then it’s still likely be clearly referenced which is helpful for editors. Also, the embedded object should always exist in the same editorial lifecycle – when it’s owner is saved, submitted, published, and deleted, the same will occur for the embedded object.