I suspect what you may have read is that there are some high-level similarities between OE Auditing and CDC, in that both can be configured to give you information about changes to tables, and that CDC is a more lightweight solution. I think there is some truth to that, if you just want information about table changes, although don't be tempted to view them as equivalent features. If you need a robust, non-repudiable audit trail, only OE Auditing provides that.
As Tom points out, these features typically only constitute the front half of a complete solution for a particular business need. Typically OE Auditing facilitates building an audit application that allows an auditor to view an audit trail of application activity. But once the data is written to the audit tables, it should be dumped from the audit tables in the production environment (via proutil -C auditarchive) and loaded into an audit archive database where it would then be read by an audit-specific application.
The typical use case for CDC would be capturing information about changes to certain tables in a database in individual table-specific change tables, as well as overall changes in a change-tracking table. These can be queried by some process that polls them for changes and then acts on them in whatever manner is desired (e.g. feeding changes to a flat file, third-party application, API, Kafka stream, whatever is appropriate, and then deleting those change records).
For the purpose of direct comparison, I suppose it is worth discussing the initial writes that happen in the production database. With CDC, writes are governed by per-table CDC policies that determine which tables are monitored for changes and what level of verbosity is required for each. That could range from something simple, like just tracking that a change has occurred, to more detailed information like the type of change and the list of changed fields and their before and after values. All of this write activity happens server-side; it is done by remote servers or by self-service ABL clients. In that sense, yes the writes are multi-threaded as there can be many such processes that are concurrently writing change-table records.
The OE Auditing feature has existed much longer (10.1A, versus 11.7 for CDC). Its operation is governed by audit events and audit policies. Broadly, there are three sets of event types that can be audited: CUD events (table creates/updates/deletes), system events (database logins, database configuration changes, etc.), and application events (where the audit data and audit context are provided by the application code running in the client). OEA has a somewhat ungainly data-encoding method for field values and it may involve writes to several different tables to record a single event. Importantly, application events are passed to the server from the client, so they can add to client/server traffic volume. As with CDC, event data will be written by servers or by self-service clients.
All that said, while it's fine to have an academic interest in how things work under the covers, I think your use of the features or add-ons should be governed by your business needs and not by whether they are multi-threaded. In general, multi-threading isn't a feature; it is a means to an end. "Multi-threaded" shouldn't be viewed as synonymous with "better" or with "runs faster".