Despite that you haven't studied the article yet, this is an interesting question Jeff.
And no, this was not covered in the article in-depth, because it involves the basics of git in combination with any branching strategy (in this case release flow). Which makes the question not only interesting but also a fair question!
Although topic B and C have the same starting point (commit), topic B is not yet merged back in main at the point of creating release/s98. No overwriting is happening there and the hotfix in this example is about something else.
However with topic B merging back into main an overwrite (merge conflict) could arise. But only if the topics (B/C) touch the same files, in all other cases git takes care of the merge without any user interference.
The same applies on merging/cherry-picking the hotfix back to main, after Topic B merged back into it.
A little summary what is in the article about merging:
These merge conflicts are solved in the pull request, before the merge is done. And because of the configured PR workflow, a pre-merging build (with the code from topic B and main) must be build and tested as prerequisite before the completion of the PR.
This all to comply to the rule of "the main branch is always in a releasable state."