Your tags look ok (c++, and Access dev - so, spot on).
As for technology? ODBC is the recommend approach. While we had a long run with oleDB technology, oleDB technology was a windows only technoloy, but ODBC while a Microsoft standard, it is and did become a industry standard. So it not limited to say windows platforms like oleDB is.
As for speed? Even when using .net, and the sql provider vs ODBC provider? You not going to find any real difference.
So, I would not suggest, or hint that anything "better" has come along. And in fact, we seeing more investment and action in and for ODBC say as compared to oleDB. In fact while sql server still supports oleDB, it has quite much dropped support for it (say on Azure - where as new specific versions of the ODBC drivers for SQL have been released).
So, while ODBC is older? It is still a good choice, but in fact a preferred choice.
Now in regards to JET database or now ACE data engine (for accDB formats), you require ODBC + the JET/ACE data engine to be installed on the target computer anyway.
Given that you in a tight coupled use of JET?ACE? Then you could consider the oleDB provider for your application - it can provide some additional options over ODBC in areas of the schema (data columns), but if ODBC serves you fine now, then I would not consider changing to oleDB.
Over time the race and choice of oleDB, and ODBC?
ODBC has won that race, and it is oleDB that's on its way out.
so we seeing for example newer drivers and ODBC features are constantly being added to ODBC drivers. For example, even when using Access front end to SQL Azure? They offered a newer ODBC driver for SQL server, and it includes things like re-connect abilities (which over the internet are required). So now ms-access can not only connect to SQL Azure, but the connection is far more robust. The point here is that ODBC is still actively being updated and supported from Microsoft, and oleDB is not.