The master tag list seems to be Finder-specific preference data though.
mdfind -onlyin . 'kMDItemUserTags=exif-stripped'that means it is now up to the other tools to catch up and make use of them.
here is a discussion about tags and extended attributes in gnome. https://blog.chipx86.com/2005/12/07/tagging-and-the-gnome-de...
it is from 2005, so not really current, but the arguments are interesting.
in short: filesystem attributes are systemwide (but you and i may want to have different tags on the same shared file) and the user needs to have permission on the files, so you can't tag files that you can read but can't change.
i believe these issues are solvable, esp. the latter would work if we have permissions to add tags but not the content of a file. (like you can rename a file even if you don't have write permission to the file)
searching can be sped up by building an index. apps that want to use tags will need to do that, just like they build an index of files already. because searching filenames is also slow.
a version of locatedb that supports xattr would help for example, see https://en.wikipedia.org/wiki/Desktop_search
and technically, file extensions are kind of like tags. and it's really ugly that they are in the filename string. that messes up a lot of things. it would be better if they were proper tags independent of the name. so you can rename a file without changing the tags, similar to the problem with EXIF.
or more importantly, you could reference a file without that reference depending on the tags of the file. your jpg/jpeg example is also a problem caused by this situation. it would go away with proper tags