So we’ve had long debates about this, and it mostly comes down to a trade-off between allowing user to store arbitrary comments and formatting in the YAML, vs making it not painful for plugins to interact with YAML.
I will say that it is rather unfortunate that YAML became the most popular way markdown documents store metadata. YAML is difficult to write by hand because it provides way too many options to write the same thing, and there’s a lot of “gotchas” such as reserved keywords, the many many ways one can write a multiline string, etc.
Unfortunately, this is really a place where standard markdown forces us to make a hard choice. The decision we made is for plugins to be able to interact with frontmatter easily. We do this by converting YAML into a JS object, which means it lose all of its YAML specific formatting and comments. This makes it easy for plugin developers to read and modify properties of a note, without requiring them to interact with an excessively complex YAML syntax tree, which would require them to understand how YAML is parsed internally.
I do understand that a very small minority of people make heavy use of YAML, and we are unable to accommodate their needs for such levels of customization. In these cases, you’ll either have to manually use js-yaml to work off the parse tree (I’d actually be curious to see how you make use of it), and avoid having Obsidian touching the YAML altogether.