I'm trying to understand the benefit of tackling this level of functionality at the WAL layer instead of the LISTEN/NOTIFY or TRIGGER ON INSERT/UPDATE/DELETE layers
NOTIFY drops events on the floor if no session is currently LISTEN-ing (due to a consumer restart, say).
You could use a trigger to write events into a log table from which they're reliably consumed and then removed, but you've now significantly increased your DB's disk activity and overhead.
Aside from performance -- which is a _big_ reason -- using CDC with the DB's WAL also lets you do capture without needing to muck about in your production DB's schema. Keep in mind that the teams producing data, vs the teams consuming data, are often different so this coordination is hard in a larger org!
You can listen to a WAL replication stream as a dedicated node without affecting performance of the original insert/update/deletes on the writer. That's not the case with either triggers or listen/notify.
