TL;DR: The primary manifestation of this bug is on posts made by users who are destroyed, where the user has commented on their own post. Technically speaking, though, there are other cases where this can also happen.
This happens because the system stores a denormalized (cached) count of comments on every post, so that it doesn't have to repeatedly query the database every time a post is loaded to see how many comments are on it.
Most of the time, this count is updated immediately - manually commenting on the post or deleting a comment will update it, as will certain automatic comments and comment deletions. However, in rare cases, this cached count is not updated immediately. To take care of such cases, the system runs a scheduled job where it updates all posts with incorrect cached counts. The issue here is that this update process doesn't run on deleted posts, so if the field is out of sync for some reason and the post is deleted, the incorrect count will persist permanently (unless the post is undeleted and the job runs on it).
In this particular case, the post in question had been posted by a known troll (details only visible to Charcoal team members), and so a moderator destroyed its account, deleting all their contributions to the site (both posts and comments). The user had commented on the deleted post, and those comments were deleted as part of the destruction process. It seems that comments deleted as part of a user being destroyed is one of the cases where it fails to update the cached count. As the post gets deleted immediately at the same time, the incorrect count persists permanently.
I can think of three ways to fix this problem:
Run the scheduled script to fix incorrect cached comment counts on deleted posts as well as non-deleted posts. I think the decision to exclude deleted posts from the job was made because there are 6-8 orders of magnitude fewer page loads on deleted posts from 10k+ users than there are overall page loads on non-deleted posts from everyone including anonymous users, so doing it on them was seen as serving little purpose. Still, though, running it once on every deleted post fixes this drawback.
Make comment deletion caused by account destruction update the cached comment count immediately just like other types of deletions that do so. This will fix the most common cause of this issue, but doesn't cover other potential cases where the cached comment count is incorrect on deleted posts, and so doesn't completely solve the issue.
Don't automatically delete comments made by a user being destroyed that are on one of their own posts. As the post is anyway being deleted, this will still have the same outcome for the general public: all of their content is being gone/hidden. This will also give further agency to 10k+ users as they can see the context of any comment conversations that took place on a post from a destroyed user that they can see. As no comments are being deleted on the deleted post as a result of user destroyal, there won't be a permanently incorrect cached comment count.
My personal favorite is fixes 1 and 3 implemented in conjunction. Fix 1 most completely solves the issue in the question, and 3 provides better moderation agency to 10k+ users and is great to implement otherwise (unless there's a reason that comments on own posts from destroyed users shouldn't be able to be viewed by non-moderators who can view the post body).