By using something like `@attachment/UUID` you don't have to refactor anything if the attachment gets renamed or modified. The somewhat unsolved issue there though is reliably keeping track of which UUID maps to which file.
If you're using regular links and rename an attachment, worst case scenario, you have to parse all notes, find all links pointing to the renamed attachment and update those, which can get expensive. Also regular path-based links can be a problem when you move the _note_ somewhere else too.
Plus how do you know something got renamed instead of the old attachment got deleted and a new one got created? This is partially a problem for the UUID-based approach too however.
Lastly what kind of link should you use to link to a note stored in another data directory? Relying on the absolute paths is too brittle, and it won't work at all when the app will also be able to run in the browser.
The "@attachment" (and "@note") thing is actually pretty useless today, but it will solve a real problem tomorrow, namely: how do you make links always work even if the resource they are pointing to gets renamed? Which is worth solving IMHO.