XML makes it easy to figure parent/child indenting in a message heading list, so you can see this post is a response to that one, etc. That is doable with relations but ugly.
Storing the names is an interesting question. Not normalized data (in the oft repeated data sense) is a big no no in relations, because in relational schemas the oft-repeated data tends to be stored in different tables. So synchronizing updates is a nightmare. Oft-repeated data in XML is less error prone, because it all tends to exist at the same oft-repeated xpath. So updates are reliable. It may not be space efficient. But disk space is cheap. Reliability matters more.
But the equivalent of "foreign keys" from one xpath to another are not difficult to do, if you are good at XML and xpath. At least if you process the query result as an array merge between two separate queries. That may sound inefficient. But it's still faster than the dog slow hierarchy modeling done with relations. (I spent 5 years working with Exist and SleepyCat, which are Java Servlet XML databases....that was before mysql began to support xpath queries over XML blobs). I think what I (sort of) proposed is eminently doable. And that it would be both easy to manipulate and zippy fast.
Post counts for users are not a problem. You need the right xpath statement to do it, sometimes but not always (in cases like that) with a little post query processing.