Bah le problème survient surtout quand le modèle est fortement relationnel (des chiens qui ont des petits, un maître, un collier, une adresse, un carnet de vaccination bref, je vous refais pas le cours de relationnel). Et qu'il faut créer ou importer un objet de ce modèle et ses relations (d'un coup).
On peut évidemment se débrouiller, mais il manque cruellement de transactions ACID entre différents "documents". Du coup, pour en bénéficier il faut tout mettre dans UN document, et parfois, ça revient à écrire des DAO ultra complexes.
En gros : ça a son domaine d'application, et ça y convient parfaitement mais ça ne 'remplace pas' une BDD relationnelle, dans les cas où effectivement, le modèle est relationnel.
Pour ma part, je me sers souvent d'une base relationnelle pour les éléments fondateurs (Domain-Driven) de l'application par contre je touche à Mongo (voire Redis et encore d'autres) pour tout ce qui est plus volatile et plutôt "standalone".
Par exemple : le modèle pur et dur (utilisateurs, permissions, associations d'objets, modélisation du projet) part en SQL, par contre l'historique des modifs d'un objet va partir dans Mongo, hBase et compagnies.