Why differentiate between symbols and strings?

Lisps have a special data type called a "symbol." If you compare two symbols with the same name against each other with eq? the result is guaranteed to be true. This is apparently not the case with strings, at least in Scheme; two identical strings are not guaranteed to be eq?/be located in the same memory location.

Most of the more modern dynamic languages, however, use "interned" immutable strings, such that any two identical strings are guaranteed to be stored in the same memory location and thus be (the language's equivalent of) eq?.

Given this development, what is the purpose of differentiating between strings and symbols in a modern programming language? Lua programs, for instance, get by just fine using its immutable strings in much the same way that a Scheme user would use symbols. Are they practically the same thing, just stored in a different namespace, as Common Lisp stores variables and functions in separate namespaces? Is this just some historical cruft that Scheme accumulated from a time when interning immutable strings was not practical, or is there some real benefit that comes from distinguishing between the two?

If you compare two symbols with the same name against each other with eq? the result is guaranteed to be true.

Wrong.

(...) in Scheme; two identical strings are not guaranteed to be eq?/be located in the same memory location.

That is correct.
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.5

Now, (Common) Lisp symbols are a nontrivial thing to grok, but totally worth it. Here begins your quest for understanding:
http://clhs.lisp.se/Body/f_mk_sym.htm
http://www.lispworks.com/documentation/lw51/CLHS/Body/f_intern.htm

Probably because it's a pain in the neck for a language to guarantee that

s := "barfoobar"
if substring(s,1,3) == substring(s,7,9)
stuff()

or

the_complete_text_of_moby_dick := "Call me Ishmael [...]"
user_input := ""
while true
user_input := user_input + get_one_byte_of_input()
if user_input == the_complete_text_of_moby_dick
stuff()


work as intended when == is just address comparison. At some point the language will have to perform work equivalent to comparing strings in order to make that hold, so why not just expose that string comparison and spend that work optimizing your string caching instead?