А теперь подробности.

1. Отсутствие учета версий в документации по встроенным функциям. На первое место я ставлю отсутствие информации в документации о том, к какой версии относится та, или иная функция, а также то, что устаревшие сигнатуры функций просто пропадают из документации, а не помечаются маркером "Устаревший". Поэтому по большинству вопросов можно найти несколько различных решений, большинство из которых не работает на имеющейся платформе. Остаётся только метод проб и ошибок. На первое место я ставлю этот момент потому, что исправить эту ситуацию могут сами разработчики. Для этого нужна только желание и сила воли. Такой подход во многом делает бессмысленным разработку любой более-менее сложной функциональности, так так в любой момент может измениться платформа и придётся переделывать всё заново. В тоже время для простых решений это не так критично.
2. Замкнутость системы. Складывается ощущение, что одним из правил разработчиков является подход: мы не такие как все, мы - особенные. Например терминология. Тип данных булево - зачем такое название. Почему не логический или какой-либо уже существующий аналог? Или субконто - неужели так сложно использовать термин "разрез" или аналитика. Кроме того, используется встроенная система контроля версий - хранилище конфигураций. Интеграция с другими системами, такими как SVN или Git повысит порог вхождения. С другой стороны, для написания кода 1-2 разработчиками её вполне хватает. Получается так, что 1с-ники живут в своём мире, и чтобы понять коллег по цеху из других областей приходится заниматься переводом терминов с русского на русский.
3. Отсутствие возможности создания собственных объектов. Я согласен с тем, что имеющиеся в распоряжении объекты 1С довольно хорошо покрывают предметную область. И для решения простых задач их вполне достаточно. Однако создать, например, свой объект для описания лога, который можно использовать независимо в различных местах, уже не получится. Да, я знаю, что можно создать глобальные модули и вызывать их в любом месте конфигурации, но это не то, это не объект - это глобальные функции.
4. Отсутствие перегрузки функций. Параметры, передаваемые по умолчанию и перегрузка функций - это разные вещи. С другой стороны, из-за отсутствия собственных объектов в 1С необходимость в перегрузке тоже невелика.
5.  Отсутствие возможности отделения описания от реализации. Я подразумеваю использование механизма, аналогичному абстрактных классов и интерфейсов в Java. Зачем это надо? Думаю, что тому, кто пишет на 1С трудно это объяснить.
6. Слабый язык для работы с базой данных. Для начинающих пользователей возможность создавать запросы в графическом редакторе - это очень хорошее решение. Написать запрос к одной таблице очень просто и наглядно. Но для того чтобы сделать вложенных запрос нужно уже создавать пакеты, а это уже проще сделать на простом SQL. Опять: для простых задач - самое то, но для сложных уже непродуктивно. Да, работая с платформой для бизнес-приложения мне хочется чтобы система брала на себя часть рутины и предлагала бы более высокоуровневые механизмы работы с БД. Например, ОРМ. Кроме того, из-за весьма запутанной структуры таблиц использовать другие инструменты для работы с БД крайне затруднительно, например MS SQL Mangement Studio имеет очень даже неплохой редактор для написания запросов и позволяет выполнять запросы по частям, например отдельно вложенный запрос.
7. Сложность использования индексов. Индексы в 1С есть, и по умолчанию их создаётся достаточно. Однако для их просмотра и анализа того, полностью ли запрос попадает хотя бы в один из существующих индексов требуется довольно сильно постараться. Хотелось бы получать соответствующее предупреждение, что тот или иной запрос или его часть не может быть обработана с помощью индекса.
8. Отсутствие модульности. То есть, я не могу быть уверенным, что функция, предназначенная для анализа штрих-кода не будет использована кем-либо для совершенно других целей. Конечно, есть подсистемы, но они больше подходят для организации объектов конфигурации, чем для реализации модульности.

Второе следствие - любое изменение приводит к тому, что необходимо обновлять всю конфигурацию. Чем меньше пользователей - тем это проще сделать, и опять - чем сложнее задача - тем сложнее. Отсюда вывод - установка только по вечерам или в выходные дни. То есть - чем сложнее система и чем большим числом пользователей она используется - тем сложнее.

Ну и ещё немного:

1) Отсутствие оператора множественного выбора. Да, можно обойтись без него используя конструкции если-то-иначе. Но код становится менее читабельным. 

2) Оператор сравнения и присваивания один и тот же. Чем раздражает? Хуже читабельность из-за необходимости анализировать как именно используется = и невозможность множественного присваивания.

3) Подсказка кода. Работает не всегда.