That would also be a practical use for those that have org-mode data, which uses the same syntax (maybe where vimwiki got it from!).
To take this in a slightly different direction—tagging nomenclature seems to me a very personal thing, and one person’s approach may not make much sense to another. I don’t really understand the use of the hash mark for example, because to me I associate that with syntax used in links, which point to one very specific, unique element. A keyword, or tag, is a clustering mechanism and thus by definition points to any number of elements collectively.
So personally I would find it very difficult to use Obsidian’s tagging features at a logical level, but furthermore I have decades of material using my own personal tagging system, hundreds of thousands of entries, there is no way I’m changing for one program! My approach is idiosyncratic and has a higher level of information density than typical linear-sequence keyword practices, but it has a pattern to it. If tagging were something the user could define a pattern for, in general, then both of our unique tagging approaches would be a possibility in the software.
The customisation field could be something like the following:
For you it would be a : in each field. For me it would be { and } with the delimiter blank. For a GTD veteran, they might fill in a @ prefix and leave it at that. Someone else might integrate with CSV-based tool output, and want comma-delineated keywords with some kind of bracket to denote the lot.
I could see a valid input being any one field, where if all three are left empty, it reverts to software defaults, and prints the hash mark into the prefix field in ghosted-grey.
