It is necessary for sane threading.
There are two sensible approaches: chain replies or flat replies.
Chain reply requires remembering Message-ID of the last mail regarding given ticket, so if there is new comment, you put remembered Message-ID into In-Reply-To field. But if you have gaps (like your own comments, which currently won't send mail - see #94), it won't help you.
Flat reply requires remembering only Message-ID of the first message, which is the mail notifying about ticket creation. If you don't have it, there is a gap too, but e-mail client can spot that In-Reply-To repeats for all the comments for given ticket, so it can group them together, even if you don't have the first mail.
I think that flat replies are more practical, even if chain replies may supposedly better model reality ("supposedly", because it doesn't have to be the case, for instance latest comment doesn't really have to address what was in the previous one, etc.). But they better model ticket-comment relation.
(I am aware of References:, but I'm avoiding this subject for now, as it would require tracking Message-IDs of all comments to tickets, which doesn't seem truly necessary, even if it would be nice feature.)
We could do chained replies by adding a message ID to the event table, then finding the last event for that ticket when the new one is created for the In-Reply-To header.
Chained replies won't work well (gap case) without References:, where all generated so far Message-IDs regarding given ticket (creating ticket mail, comment mails) should be put there.
Because you don't support specifying whether comment is a reply to the ticket body itself or any particular comment, I think flat replies are actually saner here.
Sure, that's also fine by me.