Если хочется ООП с наследованием и полиморфизмом

Если хочется ООП с наследованием и полиморфизмом...
Если хочется функционального программирования с функциями высшего порядка и map, filter, reduce...
Если хочется низко-низкоуровневого программирования с битами и байтами...

Ответ, по-моему, один: переходите на другие языки. Наша 1С - она особа весьма специфичная и неприхотливая. Это как девушка, которая выросла и работает в деревне. Её не нужны цветы, конфеты и прочий синтаксический сахар, у неё любимый шрифт - это древний и уродливый Courier New. Но вот крепким хозяйственникам она очень нравится: она многого не требует, кучу денег не забирает, косметикой не балуется, но и трактор заведёт, и поле вспашет, и скотину не потеряет. Правда, и в своё хозяйство не пускает кого попало. Словом, молодец девка, но на любителя. А тем, кто любит вот эти все шуры-муры, красоту и цветочки - нужно к столичным барышням обращаться.

А на 1С натягивать ООП, низкоуровневое и функциональное программирование - это всё равно что сельской девушке дать Mercedes Benz или Lamborghini. Ради шутки можно, но ей это в хозяйстве не нужно. Даже если её посадить за Lamborgini, она будет на свой трактор оглядываться - так воспитана...

(1) Но ведь хочется... :)

Согласен, что полноценного ООП сейчас внедрять не нужно в 1С (возможно в отдаленном будущем). Но наследование и полиморфизм кто бы что не говорил - очень крутая штука (в тему про абстрактные объекты, формы и пр.). Самого посещают мысли сделать (пусть и ограниченно) наследование и полиморфизм, скажем, в виде плагина на ЕДТ. Но пока интересной мысли не пришло в голову как это в текущей парадигме 1С реализовать.

Не понимаю, зачем...

У меня 20+ лет в 1С из них примерно 10 во франче и я не могу привести практических примеров, когда бы мы такие сели и задумались "даа... а вот был бы у нас полиморфизм..."
Я пришёл после Borland C++ Builder, где ООП вполне было и оно там было востребовано. Здесь же это в принципе не надо, здесь Предметно-Ориентированное Программирование.

Тем не менее сама 1с иногда использует подходы ООП в своих типовых конфигурациях. Например я нечто похожее видел в ЗУП. Не типовое использование обработки, когда по сути обработка представляет в себе некий объект принимающий в эскпортные переменные (как в свойства) какие-то данные и выдающая на выходе в такую же экспортную перменную некий результат, а расчет происходит внутри обработки в закрытых процедурах и функциях.