If you want to use a purely document oriented model and not have redundancies then you have to partition your object graph into a set of documents that do not overlap and have no relationships between them. I can not think of any real example that fits this model.

Start anywhere, for example, pick your users and create a document for each. Now you take the orders of each user and also put them into the document belonging to the respective user. Fine, that works. Now we come to the products they ordered, and now we have a problem. Unless no product has ever been ordered by two different users we have to duplicate product information and put it into several different documents. And there is the same problem within documents if the user repeatedly ordered the same product.

All interesting problem domains just don't fit the idea of piece of JSON without references, internally or externally. There is of course support for reference in document oriented databases, but then lets just call your documents rows in a table and your references foreign keys and we are almost back at the relational model besides that documents still have a richer model, a bit like a NF² relational model or database with deep support for XML or JSON columns.

  > Now you take the orders of each user and also put them 
  > into the document belonging to the respective user.

So the database doesn't force anything. The data modeler makes a questionable decision.

  > All interesting problem domains just don't fit the idea 
  > of piece of JSON without references, internally or 
  > externally.

These databases won't prevent data modeling using references, they just often don't provide as much support as a relational database does for doing joins or enforcing key constraints.

But that's my point - either you use documents in the way they are advertised and get redundancy or you normalize into many documents with relationships between them and then your documents just degenerate into entities.

I am not saying there are no usecases where a document oriented model fits well, but I argue that it is not a good fit for modeling your average business.

I'm guessing that "the way [documents are] advertised" refers to some of the "hello world"-style examples that are found in various blogs. I'll agree that in their enthusiasm for showing how easy it is to use put data into and retrieve data from a document store (no O/R mapping!) they assume that the reader is well-versed in data modeling. This has bitten numerous inexperienced developers. I've never seen an article recommend against data normalization though.