Because the setting is primarily meant for those wishing to use the Markdown compile options secondarily; where one might be using the native ePub 3 or PDF output for some things, they might also want LaTeX or DocBook without having to modify their entire source document to do so. In cases such as that, one would most likely not be paying attention to special Markdown characters, and any usage of them should be considered verbatim. So all punctuation that might be used to form markup is escaped. If you want to number your paragraphs with #1, #2 then you can do so.
Meanwhile it is easier to escape a character that should be escaped in a Markdown sense. For example if I want to literally print an HTML element like , then I would escape the lesser-than sign to avoid it being interpreted as HTML, like <this>. You wouldn’t want to do that with the native PDF. Hence you can type the element in bare and compile to PDF fine, then switch over to DocBook and have your text properly escaped to print as typed there as well. Going in the other direction would be more awkward.
For those cases, like the above, where you really do mean to use Markdown then that is what the aforementioned Treat as raw markup setting is for. You might also want to hide text styled as raw Markdown in your PDF, which would also be easy to do with styles on a per format basis.
That’s different, but an important distinction worth noting. In that case Scrivener for iOS was escaping its own automatically generated Markdown, in this case the product of the heading switch right above it. You will note that the macOS compiler does not escape its own automatically generated syntax—such as images, headings via Layouts and anything in the MultiMarkdown|Pandoc Options compile pane. It only escapes what we ourselves input.
The above solution is a case of text being entered via our input in that technically speaking, that’s not Scrivener generated Markdown—that’s us telling Scrivener to generate Markdown around a style. It treats style prefix/suffix text as text we have entered ourselves—and escapes it.
So, moral of the story: if you use a mechanism of the compiler to generate Markdown in an otherwise RTF document with the RTF->MMD conversion process enabled, make sure to instruct the compiler to treat it as markup.
As to your linked forum thread specifically—the use of Markdown captions in conjunction with compile settings designed for non-Markdown users to make use of the Markdown workflow—that might not be something we can fix? I’ll see if it is possible since it does make a certain sense, it being a Scrivener feature for captioning, but it’s worth noting that isn’t a global Scrivener feature for captioning—only for Markdown, and hence if you used your source to print a PDF then you would end up with bare brackets—thus Scrivener presuming that is your intention, and is trying to preserve it by escaping them.
It strives to generate a Markdown text that matches the content when printed via PDF. I’ve added a note to clear this up a bit in the manual.