Общего у ODBC и ADO довольно много. Начиная с владельца и заканчивая общими принципами работы с ними.
В среднем, для простоты понимания, можно говорить что ADO и ODBC это родные братья, но ADO для тех языков которые предпочитают работать с классами, а ODBC для языков предпочитающих функции. По возможностям и количеству фич они практически равны.
С точки зрения практической реализации, большинство ADO подключений к СУБД это всего-лишь использование моста ODBC-OLEDB-ADO с ODBC драйвером делающим реальные TCP запросы, а клиентская программа работает на ADO. Практически, вплоть до появления ADO.Net не существовало ADO драйверов.

А рекомендации... Все зависит от СУБД и языка на котором пишется клиент. В среднем, можно брать тот интерфейс который более удобен с точки зрения языка клиента (и это чаще всего ADO). Потери производительности на обертке можно игнорировать.
Но бывают ODBC драйвера с "расширениями вендора" которые дают больше функциональности. Например ODBC для SA позволяет делать push сообщений на клиента из хранимых процедур - чрезвычайно вкусная штука, но доступная только для прямого использования ODBC.

Вообще-то dblib это детище Sybase а не Microsoft. Разработанное во времена Sybase SQL Server.

Когда Microsoft купила у Sybase исходники их СУБД - купили и исходники клиентского интерфейса (dblib).
Долгое время, dblib был единственной возможностью подключаться к обоим СУБД (Sybase и MS SQL Server). Потом энтузиасты взломали этот интерфейс и родился FreeTDS.
Потом у Microsoft появились другие СУБД (FoxPro, Access) и возникла необходимость поддерживать три разных интерфейса - родился ODBC. Новый интерфейс стал "родным" для MS SQL Server и dblib в Микрософте умер.
А вот Sybase продолжала его поддерживать, но параллельно и новый интерфейс начали разрабатывать - родился CTlib. Оба интерфейса dblib и CTlib продолжали распространятся в каждой новой версии (теперь уже) Sybase Adaptive Server Enterprise. И вместе они назывались Open Client. Потом Open Client начал включать в себя и ODBC и OLE DB драйвера. Сейчас, когда эта СУБД уже носит имя SAP Sybase Adaptive Server Enterise - dblib продолжает существовать в каталоге на клиентском диске. Но я не знаю ни одного существующего проекта который не был бы переведен на CTlib или ODBC.

Не только похожее название, но и такой-же набор классов и методов - а это и есть определение интерфейса.

Да, ADO обертка над OLE DB. И да существуют OLE DB драйвера. Вот только они все разрабатывались по остаточному принципу и чрезвычайно кривы (как собственно и сам OLE DB). Поэтому практически всегда ADO используется с ODBC (через мост конечно же).

ODBC их тоже поддерживает. Примеры, ну хотя-бы xBase и Excel. В этих случаях парсер SQL запросов и собственно "сервер" находится непосредственно внутри ODBC драйвера. Этот SQL является диалектом разработанным для MS Access и практически as is скопированный во все микрософтовские ODBC драйвера для нереляционных БД, называется Jet SQL.

И вообще, мы ушли от изначальной темы топика, поэтом прекращаем.

Врут.

Да нет такой картинки. Там слишком много будет стрелочек чтобы в них всех разобраться. Или возьми эту картинку что ты уже нашел, объедини два нижних бокса (SQL/non-SQL) и добавь стрелочек из каждого верхнего бокса в нижний (за исключением ADO который только на OLE DB).

В общем ситуация простая:
У каждой СУБД есть собственный протокол общения с клиентами. SQL или не-SQL СУБД не важно.
Каждый такой протокол имеет собственный интерфейс который может использоваться клиентом - в этом случае клиент получает полный доступ к возможностям СУБД. Но эти интерфейсы уникальны для каждой СУБД и не совместимы между собой (исключение родственные протоколы).

Кроме уникальных (родных) интерфейсов существует группа универсальных интерфейсов рассчитанных на использование в конкретном языке (группе языков). Тогда мы говорим о "драйвере для СУБД" в рамках интерфейса.
Драйвер для СУБД реализует протокол общения между СУБД и машиной клиента, и выступает переводчиком между клиентским интерфейсом и протоколом. Если интерфейс SQL, а сама СУБД не SQL, то парсер языка вставляется внутрь драйвера, между собственно клиентским интерфейсом и драйвером протокола.
За исключением ADO который является полной оберткой надо OLE DB и полностью зависит от драйвера реализованного в OLE DB. Однако так как существует стандартный драйвер-мост OLE DB - ODBC то и ADO может работать на ODBC драйвере.

В результате ODBC драйвер переводит нативный интерфейс в ODBC интерфейс, потом OLE DB
провайдер для ODBC переводит ODBC интерфейс в OLE DB интерфейс, потом ADO обёртка
переводит OLE DB интерфейс в ADO интерфейс. В особо запущенных случаях ADO интерфейс
переводится в VCL DB интерфейс (для Delphi мышевозников) или обратно в нативный интерфейс
(для MS DB Links).

"А теперь мы со всей этой фигнёй попытаемся взлететь." (c)Да. Но на практике это работает и вполне успешно.

Прежде чем ужасаться, подумай, как этот "перевод" делается.