For most purposes with strings, all you want is a well-behaved layout when printed. Because of the way Lisp strings work, the source layout can easily interfere with that.
The current situation imposes a non-uniform layout on Lisp strings that exceed one line: All lines other than the first include whatever whitespace they begin with. The first line is special and does not have this problem.
Lisp strings also break up the block-wise layout of code. They don't indent with the rest of the code. If they did, they'd leave chunks of whitespace.
In some languages, concatenating literal strings is automatic, and they work around this problem by writing each output-line string on a separate line. Lisp doesn't have this, and I'm not going to suggest that Lisp adopt it.
One could try to work around the problem by starting multi-line strings in the first column, but that's impossible because they must begin with a double-quote. It's also not easy to maintain, because smart editors will reindent it for you.
All this makes Lisp strings neither good formatted strings nor good unformatted strings.
This is doubly unfortunate in Lisp, because one thing that sets Lisp above many languages is the use of inlined docstrings. Using them should not cause misleading formatting or extra work.
Unformatted strings would treat all internal whitespace as undifferentiated. Printers would be allowed to alter whitespace in any manner towards the goal of nice output style. Printers could format them according to current line-length and other style parameters.
Smart editors should indent unformatted strings according to nesting depth, like any other Lisp code.
True formatted strings would skip their first character if it was a newline. Therefore almost all current strings would be unchanged, and those whose meanings were changed could be fixed with an extra newline. Even if uncorrected, an extra newline would have no significant effect on most output.
This would make adjacent lines of strings line up properly. Remember, this is intended for strings that want full, intuitive control of the output layout.
It also would not interfere with single-line strings, which by definition don't start with a newline, unless you deliberately sneak one in with \n.