Тут дело тонкое.

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

На этом я мог бы закончить и ответить, что:
1) Утверждение Зуева верно;
2) Для многих задач (все системные и приличная часть прикладных) это не недостаток, а скорее достоинство (отделяется модель данных от архитектуры).

Однако, в компонентном ПО среди абстракций архитектуры кроме самих модулей появляются разъёмы между ними (т.е. динамические, виртуальные связи). Возникает задача описания интерфейсов этих разъёмов и виртуальных таблиц. И в Компонентном Паскале эта задача возложена на объектные ТД: ABSTRACT RECORD как описание интерфейсов, виртуальная таблица объектного типа как разъём.
Т.е. RECORD "пролезают" в архитектуру - и служат уже далеко не "для представления данных". Функции свои они прекрасно выполняют, но некоторая смысловая путаница таки возникает (хотя намнооого меньшая, чем в языках, эмулирующих понятие модуля через классы). Когда запись является типом данных, когда - интерфейсом, когда - реализацией интерфейса... Да ещё приходится налагать устные запреты на "смешивание" этих ролей - например, на наследование реализации (потому что это ведёт к ломке компонентной идеологии и всякого рода тонким проблемам).

Посему я бы вообще "откатил" RECORD практически до уровня первого Оберона, а для архитектурных задач ввёл пару спец. типов. Но это был бы далеко не OBJECT, как в Активном Обероне и Зонноне.