A lot of people also complain about the performance of strings in Haskell, so this is right where the tradeoff is today. Tomorrow it won't likely be an issue.
A really smart compiler should be able to optimize most of the inefficiency away; I'd bank on compilers improving fast enough to make seemingly inefficient things cost much less.
If I'm designing a language today for the future, I'd err on the side of usefulness.
Lua does almost no optimization at compile time* (in part so it can compile data dumps rapidly) but I find it easy to predict the performance trade-offs in various implementation choices. In a roundabout way, it still ends up easy to tune.
Still, usefulness and performance are only indirectly related. I think that was PG's original point.
* Yet oddly it ends up quite a bit faster than Python, and there's also LuaJIT.
Even if it can be made configurable, adding all those knobs and dials may add a lot of complexity.
It's useful from a convenience of programming point of view. The preferred underlying implementation is now something more sophisticated than a linked list of characters. See Data.ByteString. The programmer does not need to care much, though.
The sort of operations commonly done on strings only have a small overlap with list operations, though. I'm all for orthogonality in a language when it's practical, but I'm not sure that one is a good trade-off.
Erlang does that, and aside from space issues (on 64-bit, a linked list of character code ints means 16 bytes per char, due to alignment), it's kind of awkward. While using pattern matching on individual chars is nice, in those cases it probably makes more sense to tokenize the strings into atoms/tuples via REs, and then pattern-match on those instead. Binaries can also be used as pseudo-strings, but to me it feels like two half-solutions. (And its shell's printing a list of ints as chars when they're printable 7-bit ASCII characters is a bit odd.) Having atoms (AKA symbols) helps, though.
Incidentally, Lua's strings are all immutable atoms. That's practical most of the time, but occasionally a major liability. Lua has the obvious option of just using a different string implementation via userdata when it's a problem, though, so it can make such a daring trade-off.
Of course, just saving strings as arrays with a \0 at the end is also pretty brittle.