Многие языки, но не все, запрещают неэкранированные символы новой строки в строковых литералах. Так что JavaScript здесь не уникален.
Но мотивация действительно имеет мало общего с легкостью, сложностью или эффективностью лексического анализа. Фактически, для лексического анализа самый простой синтаксис состоит в том, чтобы разрешить любой символ, а не включать проверки в специальном случае. [Примечание 1]
Есть и другие соображения; Примечательно, что важно, чтобы программа была удобочитаемой и легко отлаживалась. Длинные строки создают дополнительную нагрузку на того, кто читает код, потому что они могут не знать, что часть текста программы на самом деле является частью строкового литерала. (Существует аналогичная проблема с многострочными комментариями, поэтому обычно считается хорошим стилем пометить каждую строку в длинном комментарии каким-либо образом, например, вертикальным столбцом звездочек на левом поле. Для строки не существует такого решения хотя литералы.)
Кроме того, неопределенные многострочные строки могут раздражать для исправления. Если строки не могут занимать строки, ошибка будет обнаружена в строке, содержащей проблему. Но многострочные строки могут продолжаться до начала следующей строки, а затем вызывать синтаксическую ошибку, когда содержимое следующей строки случайно анализируется как текст программы. Или еще хуже, что привело к совершенно неправильному синтаксическому анализу того, что должно было быть программным текстом, за которым следовал другой неверный строковый литерал, начинающийся там, где заканчивается второй литерал, и продолжающийся оттуда.
Это также затрудняет работу инструментов разработчика, таких как редакторы и подсветки синтаксиса, с текстом программы во время ее ввода.
В конце концов, вы можете или не можете найти эти аргументы убедительными, и у разработчика языка могут быть и другие эстетические предпочтения. Я не могу говорить за оригинальных дизайнеров языка JavaScript, и ни один из нас не может вовремя совершить путешествие, чтобы поспорить с ними и, возможно, изменить свое решение.
К лучшему или худшему, языки разрабатываются в соответствии с конкретными субъективными суждениями, и, если язык успешен, эти суждения становятся постоянными характеристиками. Это вещи, которые вы должны принять, если вы используете язык, и о них обычно не стоит зацикливаться. Вы привыкаете к ним или находите другой язык для программирования с его собственными синтаксическими особенностями.
Когда вы разрабатываете свой собственный язык, вам нужно будет решить большое количество синтаксических вопросов, и вы, несомненно, столкнетесь со случаями, когда ответ не является четким, поскольку не существует объективно правильного уникального решения. Что бы вы ни делали, кто-то захочет с вами спорить. Возможно, вы можете отослать их к этому ответу.
Примечания:
На самом деле существует историческая причина, по которой нельзя использовать многострочные строковые литералы, что гораздо яснее, но более или менее неактуально в течение нескольких десятилетий.
Однажды обычные файловые системы рассматривали текстовые файлы как линейные массивы строк фиксированной длины (часто 80 строк символов, соответствующих карточке Холлерита). Одним из преимуществ такой файловой системы является то, что она может мгновенно перейти к определенному номеру строки в файле, поскольку все строки имеют одинаковую длину. Но в любом случае для систем, в которых программы вводились на перфокартах, линии фиксированной длины были лишь частью среды.
Чтобы все строки имели одинаковую длину, строки должны быть заполнены пробелами. Это, очевидно, сделает многострочные строковые литералы неудобными, и именно поэтому C никогда не допускает многострочные строковые литералы, вместо этого полагаясь на синтаксическую особенность, в которой последовательные строковые литералы автоматически объединяются в один литерал.
В конце концов, файловые системы с фиксированной длиной строки оказались непопулярными, и я не думаю, что вам нравится сталкиваться с такой в наши дни. Но внимательное прочтение стандартов C и Posix показывает, что такие файловые системы все еще должны быть пригодны для использования в соответствии с реализациями, в результате чего должна быть подготовлена полностью переносимая программа для обработки ограничений длины строки на выходе и конечных пробелов на входе.