Some notes on declaration differences
There are subtle difference here and there, but the general principle is that whether the field was defined in the frontmatter or as inline field it shouldn’t matter.
One difference is related to accessibility, where in Dataview frontmatter fields are accessible through file.frontmatter in addition to just the field names. Similarly Templater has a tp.frontmatter access, but not direct access to inline fields. In Tracker there are also different ways to access the frontmatter fields, versus the inline fields (with some caveats of its own in either implementation).
Another difference is that declaration syntax varies on whether you’re using the frontmatter or inline fields. Lists and/or links have caused more than a little frustrating at times, since it’s not a clear cut which syntax works where.
Handling of links is also a vital difference when it comes to frontmatter vs inline fields. Both with regards to the syntax, but also in how Obsidian handles the links, both related to backlinks, inlinks and if you rename a “link” placed in the frontmatter. E.g. it’ll not follow the rename strategy which applies in the rest of the vault (with the exception of within any code blocks). The Frontmatter Links plugin tries to counter this behavior.
Redundancy in frontmatter
In some circumstances the file creation and modification times can be changed due to sync tools, file system issues, backup issues, or what not. Another case is when importing files from a different system. In all of these cases, it renders the metadata associated with the actual file possibly incorrect.
Personally, I’ve imported many files from the Day One app, and it uses a slightly different file format, so when I imported/transformed these file, the file creation date (of the new files) was naturally set to the day of the transformation. Luckily, the file had the creation date as metadata, so I could transform that into my Obsidian variant of those files.
Another case is if you do daily journaling on different mediums, and move them into Obsidian at a later stage. Here you’re also wanting to be able to set the creation date related to when it was written, and not when it was created as a digital file. I’ve also done this if I write a journal entry in retrospect, where I then set the creation date to be the actual date of the entry.
The last case I would highlight, is if you change metadata associated with your entries, and you don’t really want neither the creation nor modification date to reflect that. Like I changed from tags to a field for some information, and that would of course trigger the actual file modification, but I wouldn’t like it to trigger the entry modification.
