I use them. But I may not be able to convincingly argue that the project as a whole isn't useless... so you might be in that sense right. 
I'd thought you were somewhat convinced by the argument that being able to put sigils on array classes is sort of the "composition API" for those sigils. You can't say @foo: but you can say @[foo:] and [@foo]:, and there are known mechanisms for picking those structures apart, with this extending indefinitely e.g. [@[@[foo:]]]:
But either way... since they're useless... why don't we deal with this conundrum for now by having you not use them. We'll put a pin in it for later discussion, after all the other problems are solved, and maybe that would be a good time to take them out.
Using words+paths+tuples vs. strings have advantages. Word symbols are interned (words that are spelled the same look up to the same UTF-8 bytes in memory) which all things being equal makes storage less, comparisons faster, etc.
Limiting library names to what's legal in words has the advantage that you can turn that word into other forms, so if you wanted to make some dialect that mentioned libraries named by symbol you'd have those parts to manipulate. You could use them as keys in objects, etc.
And that manipulation being easy is an advantage of having things like a version tuple be part of a path. It's easier to parse because much of the parsing is already done for you, and easier to do things like compose...with the usual niceties of having the structure and checking and such all working for you:
>> version: 1.1.20
>> first version
== 1
>> version.3
== 20
>> compose @library/(version)
== @library/1.1.20
>> curtail compose @library/(version)
== @library/1.1.20
>> version: null
== ~null~ ; anti
>> compose @library/(version)
** Script Error: non-NULL value required (see MAYBE, TRY, REIFY)
** Near: [@library ** (version)]
>> curtail compose @library/(version)
>> compose @library/(maybe version)
== @library
(See explanation of CURTAIL)