I wouldn’t worry about technically distinguishing between tags and attributes. Tags are, after all, attributes.
The built-in $Tags attribute is a set-type attribute, which means it can hold a series of strings. The meaning of the strings is whatever you want. They could be a set of names of colors, or a set of names of emotions, or a set of brands of canned tomatoes, or whatever. There are neither rules nor best practices for tagging. Tags are completely idiosyncratic, contextual, with no objective meaning. The downside of this is the lack of structure.
For structure, you can create a virtually unlimited number of attributes. There are several kinds of attributes: strings, colors, numbers, dates, sets, lists, files, URLs, booleans, etc. Attributes hold information about your note(s). You have considerable flexibility in designing and using attributes. Say, you want to make notes about operas. So you can create attributes for: $Composer, $Librettist, $FirstPerformanceDate, $AriaList, $SIgnificantRoles, $SeenPerformed, etc. Some of these are string attributes, some dates, some lists, some boolean.
You could load all the information in those attributes into $Tags, also, but you’d end up with a bit of a messy text that is hard to figure out. Parsing $Tags for meaning is usually difficult. Most people who use tags a lot end up keeping a sort of cheat sheet to explain to themselves what their intention for such-and-such tagging scheme is. It’s usually not difficult, on the other hand, to guess at the intention of an attribute – $AriaList probably doesn’t refer to brands of canned tomatoes.