To summarize the reasoning I expressed here:

• no short default description like "Reply" will cover all use cases (semi-related comments, additions to previous comments);
• it looks like user-added text, which it isn't, especially because of the inability to customize it;
• with the tags, it's superfluous.

In T249391#6282880, @Esanders wrote:

We should create a separate task about considering if we need change the current auto-generated summary. It is currently:
/* Topic heading */ Reply

but we could also consider adding the replied-to user:

/* Topic heading */ Reply to ppelberg

or a snippet

/* Topic heading */ Reply: I agree, the interesting thing...

Another idea
In this comment, @geraki suggested an approach similar to what @Esanders mentioned in T249391#6282880: show some of the contents of the comment within the edit summary, as Flow does.

I strongly oppose to inserting a snippet from the comment itself into the edit summary, for the following reasons:

1. It's not a summary of the comment, it's duplicating the same text to multiple places. I.m.o. that's a bad habit: only after reading the same thing twice you realize you just read the same thing twice (I get a feeling from it similar to the one I get from needless cross-posting).
2. It's actually cluttering the history etc. pages with a lot of text that contains hardly any information, related to the amount of text. (One of the reasons that makes Flow history pages pretty useless, i.m.o.)
3. From @Whatamidoing-WMF I got the impression (here) that inappropriate statements in edit summaries —aside from "almost all of the edit summaries for replies look useless"— might be an important reason not to add an edit summary field, or why it was never added. Using a snippet from the comment conflicts with this 'abuse prevention' argument: any inappropriate statement in the start of the comment will also be included in the —(afterwards) uneditable— edit summary. (Besides: such a reason should be part of a broader discussion and development decision about edit summaries in discussion namespaces.)

I say:

• As long as the edit summary can't be customized, I'm convinced that an empty summary (apart from the /* Topic heading */) is the way to go; for the reasons given above.
• As soon as we're able to customize the edit summary (T249391), something like "Reply to [name of the replied-to user]" would be a good option to consider as a prefill, since after all that's the main purpose of the Reply Tool and would fit (not all, but) the vast majority of the uses of it, and would actually be informative on history pages.
• Some way to customize the prefill would be great, e.g. by putting something like mw.messages.set('dt-reply-to':'@$1') in common.js. (Or mw.messages.set('dt-reply-to':'') for the ones who always want to type their summaries themselves.)

General thoughts about pre-fill, snippet, and behaviour with/without customisable summaries

I agree with @Marc that the start of the comment isn’t necessarily representative of the whole, so it doesn’t work as a summary, only a locator. [And for locators we'd be better off with some kind of wiki-unique permanent anchor (WUPA™!) but that's a whole different story.]

Good point about solidifying regrettable content into the summary where it can’t easily be retracted. Senior contributors know that what they put in the summary goes on the record and shows in people’s watch lists, and are (or at least should be) careful as a result. They may be astonished to have this done outside their control.

The content you (don’t) include in an uneditable, invisible summary will differ from what's desirable as a pre-filled editable default.

For example, someone might hit the "wrong" reply link, but still publish the comment because the indent level looks right, not knowing that the summary will be “Reply to Soandso”. Or they might consciously choose that link to get the indent level, but be responding to multiple people above them, and would like the summary to be “Reply to X, Y, and Z” rather than “Reply to Z”. But they can’t see that's what he outcome will be, because we're hiding it from them and taking away their choice. If we’re going to do that, then better to say nothing than say the wrong thing.

Questions about empty (topic title only) summary

Regarding the duplication of Reply ... Tags: Reply – is there anywhere in the UI where you see the summary text but not the tags? (I.e. somewhere that removing the first “Reply” might create problems?) Also note that we’d be locking in the Reply tag by attaching end-user significance: it becomes more than just a stats tracking device. (Is tagging part of core, or an extension? Would we be creating a dependency between two extensions?)

How would an empty summary interact with the user preference “Prompt me when entering a blank edit summary (or the default undo summary)”? Should that become “Prompt me when entering a blank edit summary (or the default undo summary), except on talk pages”? (I.e. for consistency, remove the reminder for talk section edits as well as for DT?)

Topic titles

Some pages have long discussions with sub-headings. Is the assumption that /* Topic heading */ would be the top-level heading, rather than the immediate subhead?

The subheadings are often not self-explanatory without the context of the parent, e.g. Support/Oppose/Discussion, or “Arbitrary break”. It’s technically possible to insert /* Heading */ /* Subhead */ /* Subsubhead */, for a meaningful result, e.g. /* RFC on something important */ /* Support */ Reply. But I can picture the howls of outrage and confusion expressions of mild consternation that might cause.

In T254117#6334993, @Pelagic wrote:

Regarding the duplication of Reply ... Tags: Reply – is there anywhere in the UI where you see the summary text but not the tags? (I.e. somewhere that removing the first “Reply” might create problems?)

For example in watchlist notification emails, or page histories shown by Navigation-Popups-Gadget. However, I’m not sure if this summary contains any useful information: on a talk page simply a /* section summary */ means for me that it contains a reply; what else would it contain? Talk pages are usually used for starting discussions and replying, after all.