They're talking about relations between data. For example, when you delete a user, you may also want to delete their stored data.

To some degree, this is less of a problem with document databases, because they don't force you to chop your data into small parts like relational databases do (e.g. you can have lists of that user's stored data as part of the JSON document). But you will likely still need some relations at some point.

Chances are you have a layer in your application code which ensures these relations that way.
Which is fine in my opinion. With relational databases, there's also often some relations which you cannot model in the database.
But yeah, it requires somewhat more software architecture awareness, to not lump the relation checking logic into general application logic. And you can't connect a second application to that database, without having to implement the relations another time or at least pulling them out into a shared library.