I'd also argue that the limitations of markdown allow me to focus on actual content and less on the presentation. I have little use of all the features of a markup language if I can't remember how to use them.
That said I am not sure what the solution is to that since your docs may need structure my docs dont need. Therefore you cant solve the "semantic" outside of a "namespace" of what you agree in your organization.
E.g. you may decide architecture diagrams are in Mermaid but that is by no means a stanfard and my org uses embeded svg.
So to go full circle... you are right just use HTML. After all it's semantic isn't it ;-)
I don't think this belief is valid. The whole purpose of markdown is to serve as a easy to read format that is publishable as plaintext and has minimalist standardized formatting and styling. It's something for humans to read and write without requiring specialized tooling.
For this purpose, "structure" is neither a requirement nor a valid concern.
> E.g. you may decide architecture diagrams are in Mermaid but that is by no means a stanfard and my org uses embeded svg.
That's a trait of your organization, not Markdown. Mermaid is ubiquitous, and used extensively in virtually everywhere in the internet. If you chose not use it that's a personal call you're making, and not related to Markdown at all.