A number of factors influence choosing the ODBC approach. These include a requirement for high performance, more granular control over the interface, and a small footprint.
The ODBC API is considerably harder to code than the object-based interfaces, but provides a finer degree of control over the data source. Unlike other data access technologies (such as ADO, RDO, or ODBCDirect), the ODBC API has not been made "bullet proof." While it's fairly easy to create ODBC errors during development, the ODBC API provides excellent error handling with detailed error messages. In general, developing, debugging, and supporting an ODBC API application requires a lot of knowledge, experience, and many lines of code. As a general rule, developers prefer to access data by using a simpler, higher-level object interface such as ADO.
ODBC is not suitable for nonrelational data such as ISAM (Indexed Sequential Access Method) data because it has no interfaces for seeking records, setting ranges, or browsing indexes. ODBC simply was not designed to access ISAM data. While you can use the Microsoft Jet ODBC driver to handle ISAM and native Microsoft Jet engine data, what is really happening is that the Microsoft Jet database engine converts the ISAM data to relational data and then provides limited ISAM functionality. Performance in this situation is slow due to the extra layer imposed by the Microsoft Jet engine.
If your application requires very fast access to existing ODBC data, and you're willing to write many lines of complex code (or you already have a lot of ODBC code available for reuse), ODBC is a good choice.