Если задаться целью ответить на поставленный вопрос - так
почему же были выбраны ЕК (без сильного вдавания в подробности что лучше и что хуже) - то (как мне кажется), необходимо учесть, что ЕК хороши для нумерации справочников (CustTable, VendTable, BankGroup и т.д.), а ИК - нумерации документов, проводок (CustTrans, LedgerTrans, InventTrans и т.д.). Безусловно, с точки зрения сложности разработки некоего интерпретатора, коим является ax32.exe - лучше остановить выбор либо на ИК, либо на ЕК, причем обработка ЕК проще, чем ИК. Программно проще (не надо лишний раз заморачиваться на join-ы).
Учитывая некий экономический эффект (все-таки систему надо раскрутить и продать) - возможно и было принято решение в сторону упрощения разработки интерпретатора (еще ж слой sys писать надо) для получения максимально быстрой отдачи. А потом уже наследство легло тяжким бременем
Кстати, внесу еще один аргумент в пользу ЕК, про который в данной дискуссии забыли. В любой БД существует задачка восстановления/исправления данных (когда необходимо обратиться напрямую к СУБД, минуя систему). Уверяю, что восстанавливать данные в системе с ЕК ГОРАЗДО проще, при условии, что не используются средства Аксапты. В 1С например в лоб - вообще не залезть, чего не скажешь про Аксапту. Ну и как следствие - всевозможные экспорты/импорты данных из сторонних программ
2mazzy - функция renamePrimaryKey - весьма порочная.... Не стал бы рекомендовать ею пользоваться - ибо уверен, что там, где эта функция корректно отработает - там можно и вручную данные удалить/создать, в то время там, где ею захочется воспользоваться это делать катастрофически нельзя (напр переименовать клиента, если по нему уже прошла куча операций)
Хотя, на безрыбье как говорится и рак рыба... все ж лучше чем ничего