ADO is not a Jet-specific access method -- it is an abstraction
layere, like ODBC, intended to function as a common interface to
multiple data storage systems, each with its own specific
functionality. That means it provides all functions that are
supported by almost all db engines, but doesn't necessary support
functionality that is supported by only a few platforms (or
supported in very different fashions in different db engines, as is
the case with replication).

When Microsoft went down the ADO garden path, stupidly recommending
it as a replacement for DAO with Jet data (something they've since
reversed), they were smart enough to realize they needed to provide
some support for Jet replication that was similar to ADO in its
architecture (one of the advantages of ADO against Jet over DAO is
that it's thread safe), and so they created JRO.

JRO should have together all the Jet replication functionality into
a single library, making the use of DAO + TSI Synchronizer obsolute.

But it didn't. See:

 What does DAO have that ADO/ADOx/JRO do not have
    (and might never have!)
 http://trigeminal.com/usenet/usenet025.asp

So, like with all Jet operations, DAO is still the best method for
working with Jet data.

And that's why most of the code examples (with the exception of the
Microsoft Knowledge Base) are in DAO.