So this document you show represents one blog post and those are the comments, tags, likes, etc? If that's the case this isn't too bad.
1.
db.posts.find({'$or':[{'comments.author.id':{$in:[some list of friends]}}, {'likes.who.id':{$in:[some list of friends]}}, {'tagged.who.id':{$in:[some list of friends]}}]}).sort({date:-1})
This will give you the posts all your friends have activity on sorted by the post's date descending. I don't think mongodb yet supports advanced sorting (like the min/max of the dates in comments, likes or tags) so sorting by either one of comments, likes or tags or sorting on post date is your best bet with this model.
2.
Personally, I would setup a separate collection for dumping a user's feed events into. Then as events happen, just push the event into the array of events in the document.
They will automatically be sorted and you can just slice the array and cap it as needed.
However with documents that grow like that you need to be careful and allocate an initial sizable amount of memory or you will encounter slow document moves on disk.
See the blurb on updates
Edit additional comments:
There are two ways to do it. Either a collection where every document is a feed event or where every document is the user's entire feed. Each has advantages and disadvantages. If you are ok with capping it at say 1000 recent feed events I would use the document to represent an entire feed method.
So I would create a document structure like
{userid:1, feed:[(feed objects)]}
where feed is an array of feed event objects. These should be subdocuments like
{id:(a users id), name:(a users name), type:(an int for like/comment/tag), date:(some iso date), postName:(the name of the post acted on), postId:(the id of the post acted on)}
To update this feed you just need to push a new feed document onto the feed array when the feed event happens. So if user A likes a post, push the feed document onto all of user A's friends feeds.
This works well for small feeds. If you need a very large feed I would recommend using a document per feed entry and sharding off of the recipient user's id and indexing the date field. This is getting closer to how the very very large feeds at twitter/fb work but they use mysql which is arguably better than mongodb for this specific use case.