pivaесли есть опыт, знания и работа на шарпе, то какой смысл ломиться в 1С ?
Из-за распространенности 1С, рано или поздно придется решать задачи интеграции. При этом не всегда вам объяснят по каким правилам она должна проходить (за исключением самых общих требований). В этом случае даже минимальные знания 1С упростят решение поставленной задачи.
pivaОпять сторонникам ООП в 1С будет очень и очень не сладко.
Опыт классического программирования позволяет с некоторыми оговорками внедрять в процесс разработки на 1С современные подходы. Например, модульное тестирование или непрерывную интеграцию. "Чистые" 1С-ники об этом ни сном ни духом, соответственно качество выдаваемых решений (при этом они в один голос говорят, что клиент хочет "по-быстрее") очень низкое.

Я много лет плевался на 1С, но их решения очень дешевые и потому очень популярные, вот уже года 3-4 работаю с ней очень плотно.
Мой совет: если есть желание разрабатывать учетные системы (не важно на каком языке), то 1С нужно знать в обязательном порядке хотя бы на троечку.

Koala22 и как это можно использовать в 1С? Расскажите поподробнее, pls!
У нас так:
1) Тесткейсы группируются во внешних обработках
2) Если необходимо тестировать неэкспортные процедуры, то перед тестированием мы выгружаем модули в файлы, программно добавляем слово "Экспорт" куда надо, потом загружаем эти файлы назад, проводим тестирование, после загружаем в конфигурацию первоначальный дамп
3) Есть спец. тулза, которая в определенном порядке запускает эти обработки передавая их в 1С с параметром /Execute
4) В обработке в событии ПриОткрытии запускается алгоритм проверки, в конце которого стоит ЗавершитьРаботуСистемы. Это позволяет автоматизировать весь процесс проверки.
5) По окончании работы обработки формируют отчеты с результатами тестирования
6) Тестирование запускаем по ночам. Сейчас продолжительность около 8 часов. Субъективно кажется, что 1С тормознутая.
7) Часть инструментария реализована на других ЯП (Delphi, PHP, Python).

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

Недавно родилась идея сделать разбор всего кода конфигурации, чтобы проводить различные анализы, например, сколько раз вызывается сервер из клиентской процедуры. Проблема очень актуально с появлением платформы 8.2.15, в которой вызов серверных процедур формы из событий ПриАктивацииХХХ действительно стал вызывать проблемы, как об этом написано в документации. Глобально хочется иметь инструментарий проверки кода на соответствие внутренним стандартам. Частично мы его реализовали в виде внешней обработки, но есть более сложные ситуации (как описанная выше), которые на языке 1С писать уже бесперспективно. Планируем делать на PHP.