That depends how much of your data is fixed, and how (often) it's updated.
If you constantly update your Article array (as in blogging systems), documents will eventually grow, wouldn't fit original disk space and will be moved by MongoDB on disk. This will cause storage size to increase massively, fragmentation and will harm performance (IO, indexes that have to updated with pointer to documents on file system). Plus these kind of documents tend to grow beyond 16 MB.
If it's a book catalog for example - where data seldom changes - embedding can be considered as it implies a more convenient / simple data model.
You also have a third option of embedding / adding writer data (Name, Email) inside Articles collection, leaving your application code to update all documents once a writer email changes, if you care about it.
So, if writer has 8000 - 10000 articles/poems/books (I expect those numbers to vary and you shouldn't count on this assumption), embedding option means unpredictable avg. document size and increasing padding (factor). I would go against embedding in that case.
As for your second concern, normalization in this case implies a slightly more concise query patterns: for example you don't have to slice an array in order to fetch 20 topmost articles.