FYI, in next week's MediaWiki release, preview=1 will suppress this again, and disablelimitreport=1 will no longer suppress this. (This is a side-effect of the changes for T314260, we didn't really think how this would affect API use.)

I'm not sure if the banner should be present on parsed HTML or not in general. I think it makes sense when parsing the current wikitext of the page (e.g. https://en.wikipedia.org/wiki/Special:ApiSandbox#action=parse&format=json&page=Talk%3AS._A._Beach&prop=text). If it was separate from the parsed page content, then at least some editing tools like DT and VE would need to separately take care to display or hide the banner after making an edit.

Do you think that just making preview=1 suppress it is enough (assuming we document it as a supported feature and don't break it again), or should we think about some other options?

The use case being you have just edited a page and the banner should be shown. An editor like VE which updates the page dynamically does so by fetching the new page contents from action=parse, so this needs to return the full rendering of the content area, including this banner.

I'm still unsure as to why something that's supposed to be part of the interface shows up on parsed HTML

This is also true of section edit links

especially when no specific wikitext triggers the banner.

the wikitext lacking any signatures triggers the banner. It may be less intuitive that section edit links, because its the lack of something rather than the presence of something (a header).

Setting disableeditsection feels like a hack

This is the only existing option for disabling page editing UI within the content. It would probably be better if it was called disableeditinterface but I don't think it's a hack.

I would not expect the banner to be in the parsed output since action=parse is meant to parse the content (wikitext) of the page, and the banner is not present in the wikitext.

Do you think that just making preview=1 suppress it is enough (assuming we document it as a supported feature and don't break it again), or should we think about some other options?

I'm alright with just having preview=1 suppress this (and for the documentation, definitely, since this came as a surprise to me); see below for some ideas.

This is also true of section edit links

The same could also be said with the NewPP limit report (albeit it remains a comment) — no specific wikitext triggers it but we do expect it to be there unless explicitly disabled. Those who use the API (like me, in this case) expect it since it is native to the MediaWiki core and it's documented on the action=parse's help page.

But unlike the section edit links and limit report, DiscussionTools (as of now) runs off of an extension. This specific problem didn't appear to me on my testing wiki because the extension wasn't installed there. Testing it on the English Wikipedia surprised me since there was no documentation that said API output would be affected, nor did I do something (or did not do something, such as include a disableeditinterface parameter) that led to the banner showing up. Specifically in P32287, all I needed was how a template would look on a talk page and since I am intentionally passing no sections (and hence don't find the need to enable disableeditsection) and no signatures, I expected just the template output, nothing more. With DT, this is no longer the case and I get more than I asked for (text={{copied|from=A|to=B}}).

An editor like VE which updates the page dynamically does so by fetching the new page contents from action=parse, so this needs to return the full rendering of the content area, including this banner.

Would it be possible for the parser to return hidden metadata (an HTML comment or a blank <span> or possibly an action=parse prop to avoid modifying the parser HTML entirely) that VE would be able to detect so that it can append the banner on the page after loading the parsed content? I'm sure the banner (considering it's only 1,199 bytes long in the output linked above) could fit in client-side JS without that much of a performance hit, but I'm not savvy enough in extending the API to know if that's in the realm of possibility.

append the banner on the page after loading the parsed content

I would rather not do this. It would result in delayed loading, and a repaint of the page as the height changes.

It doesn't seem to be documented anywhere. You can find the code affected by this option here: https://codesearch.wmcloud.org/search/?q=getIsPreview. Seems to be a lot of random things in random extensions, and also the {{REVISIONUSER}} magic word.