Without knowing a lot more about the system it's difficult to answer your question (bar the specifics in update 2). It's possible, for example, to think of comments referencing articles, or articles referencing comments. With more details, especially use cases, it's likely that one design would likely come out in front.
Nevetheless, in the absence of further information, it's your second bullet point, composition, which strikes me as most natural. To wit, articles have a list of comments, as well as a title, a body, etc. You might or might not have a CommentsList intermediate class. In any case, you can create, delete, and get references to comment objects. Comments have text, links, formatting, etc.
Re update 2, I agree that loose coupling is desirable. However I disagree that passing a reference to an Article to the Comment constructor makes sense, all other things being equal. This introduces a cyclic dependency -- because the Article has a list of Comments -- and also therefore a higher degree of coupling than would be the case if you took the alternative "top-bottom" approach of passing the Comment to the AddComment method of the Article class.
With this "top-bottom" approach, the Article could either have a NewComment method, in which case the Article itself creates the Comment object, or it could have an AddComment method as you suggest. Which is preferable depends on the details of the requirements: for example a requirement to have different kinds of comments (or even to share comments between articles) would suggest the AddComment approach.