Хотя это – вопрос риторический, поскольку зависит от конкретной задачи, он мучает многих разработчиков, размышляющих об архитектуре приложения. Думаю, надо обратиться к теории – она даст однозначный ответ на то, как правильно поступить. В первом случае мы видим типичную агрегацию или композицию (к сожалению, в исходном коде не видно реализации), во втором – наследование. А раз так, то в первом случае мы получаем некий класс, в котором есть возможность оперировать стандартным списком указателей, а во втором – класс – список с расширенной функциональностью. Понятно, что если наша задача – реализовать список объектов некого типа, выгоднее использовать наследование. Если же речь идет о моделировании объекта предметной области, играющего не только роль списка, но и другие роли, то следует избрать первый вариант. Можно также для этих целей воспользоваться паттерном «Фасад» или «Посредник». Что же касается плюсов и минусов, то они при правильном выборе подхода очевидны. Чем точнее будет выбрана реализация для моделируемого факта, тем проще будет манипулировать его экземпляром в нашей модели. Наличие дополнительного кода я бы не счел существенным недостатком, потому что количество кода не есть однозначное мерило правильной организации приложения. К тому же, для удобного пользования списком все равно придется перекрывать часть методов и свойств, если планируется использовать нечто отличное от пойнтеров. Но вот, например, сокрытие приватных свойств и методов списка за фасадом враппера, как Вы верно отметили, является, на мой взгляд, гораздо большим преимуществом. В целом, тема списков уже набила оскомину многим дельфи – разработчикам, потому что постоянно приходится писать одно и тоже. Надеюсь, появление дженериков в Win32 как-то решит эту проблему.

Класс TList, особенности работы с ним и отличия его реализации в разных версиях Delphi, разобран как раз в книге, которую Вы представили тут – ночью об этом читал. Цитата оттуда:
Денни Торп (Denny Thorpe), один из самых толковых разработчиков в отделе научных исследований компании Borland, в своей книге “Разработка компонент Delphi” (Delphi Component Design) [23] сказал следующее:
“TList – это рабочая лошадка, а не порождающий класс… При необходимости использования списка создайте простой интерфейсный класс (порожденный от TObject, а не от TList), который будет иметь только нужные вам эквиваленты свойств и функций TList, и возвращаемые типы значений функций и параметров методов которого соответствуют типу хранящихся в списке данных. В таком случае интерфейсный класс будет содержать в себе класс TList и использовать его для хранения данных. Реализуйте функции и методы доступа к свойствам этого интерфейсного класса в виде однострочных вызовов соответствующих методов или свойств внутреннего класса TList с применением соответствующих преобразований типов”.

Ну, там прямо написано, где имеется в виду совсем старые версии Delphi, а где – Delphi 5 или иные. Я пишу на 7 second edition, поэтому для меня почти всё актуально, ведь она не так отличается от 5-ки, как, скажем, 8-ка или последние версии, 2007 например. Хотя спасибо за совет

у меня написан шаблон, в смысле, текст модуля, который является копией TObjectList и изменяет его на TObjectMyType, где MyType, как и понятно из контекста, мой тип.

вот таких вот потомков Tlist у меня уже добрый десяток.