No one likes to play with comment.module, it's long neglected, manages to just about keep up with its basic tasks OK (making it not so broken as to invite a flood of patches), but singularly fails when you want to do anything clever with it due to fairly fundamental architecutural issues (making it a pain to write patches for). But core standards are improving, and it can only limp along for so long.
The long term, pie in the sky (but equally unpopular in some quarters) solution to this has been making comments into nodes - there's a nodecomment module for Drupal 5 and 6, used on some high profile sites, which aims to be a drop-in replacement for the core comment module for this purpose.
The primary argument against doing this in core has been performance. Since September I've put a lot of work into speeding up node_load(), and it's now equivalent to comments even when displaying large numbers of nodes. With node_load() caching and some other pending optimisations, nodes might even get faster (at least on straight loads) in Drupal 7. Of course loading isn't the only problem, a write heavy site with MyISAM tables is going to have trouble if all the reads and writes hit the node table, as opposed to both the comment table and the node table, but nothing stops people building sites using only nodes which are write heavy anyway.
The other argument against comments as nodes is that 'comments aren't content' - i.e. they're attached to content, but not first class items in their own right. For example, you don't want comments showing up as individual items in search results - you want the node and its comments searched as currently happens in core. The flipside to this is if I'm searching for some text which appears in comment 2000 of a 4000 long thread, when I search, I'll be taken to the first page in the thread, on which that comment doesn't appear. We can solve the basic indexing problem by excluding 'comments' from the search index in their own right, but appending them to the indexed markup for parent nodes same as now, so there's ways around this, but they require more than just a straight conversion.
There's been some discussion back and forth around these issues, both in #drupal on irc and in the issue queue. Here's a quick summary of the possible approaches, and an overview of the current state of things:
1. Leave things as they are
comment module has a very clunky API (look at comment_render() if you want an example). Some modules support this API - like fivestar, comment upload etc. - but those modules have to do everything twice, once for nodes, once for comments. The general consensus of discussions so far is against making comments a 'fieldable' item, since this would require most of the complexity of nodes to work properly, and have all of the performance penalties.
2. Comments as nodes
Converting comments to nodes would be a large undertaking - we'd need to rewrite comment.module from scratch. It'd mean we have a much more robust API for comments (not that the node api is that great either, but it's slowly being improved). Comments would be fieldable, but while comments vs. nodes come out about even for loading in benchmarks, we'd have to handle the fact of Drupal.org having over 1 million nodes overnight, and the additional weight on inserts and table size.
3. Forum posts as nodes
Forums are one area where the original post is on an equal footing to the replies to it, and most forum software - phpbb, vbulletin etc. gives moderators easy and powerful tools to split forked discussions into new threads, merge similar discussions together etc. etc. - something which comment mover tries to do in contrib - but dynamically changing a piece of content from a node to a comment isn't much fun - we don't even support node type changes in core yet.
4. Both
chx has written up a post describing a small non-fieldable item API - as a generic storage method for lightweight items. This would be ultra-lightweight comments - no fields, no hook_comment(), with link changes handled in the theme layer or somewhere similar. In addition, we'd support nodes as comments in core as an alternative - possibly allowing for combinations of both on the same site. So the blog runs non-fieldable items, but the video clip responses section runs nodes as comments due to field support. This would allow for both extremes to be catered for, but it's got some interesting issues to solve both from an architectural perspective and a UI perspective - at least if we don't want both systems mutually exclusive.
So, anything apart from shipping with a hamstrung and broken module in Drupal 7 is going to require a fair bit of refactoring, and at the moment there's no patches tackling any of these issues directly. But with fields in core looming very close, now seems like a good time to thrash this out.