1) Hai ben compreso
2) Hai ben compreso, ma ci tengo a sottolineare che non è una regola assoluta, solo quello che è frutto della mia esperienza. La stessa che m'ha insegnato che ogni scenario ha le proprie caratteristiche e le proprie soluzioni migliori.

Non mi dilungo in altre riflessioni. Ti riporto invece una soluzione implementata in un gestionale su cui ho lavorato (implementato con standard J2EE, ma i concetti potrebbero essere riadattati nelle tecnologie che usi).

Un audit control semplice non centra molto con le logiche di business, ma è una feature tecnica utile maggiormente all'AM e al data-fix.
Per questo è bene tenere i moduli che li gestiscono, separati quanto più possibile dai moduli applicativi. La strada dei trigger in teoria era(è) una buona soluzione perchè separata dal resto del sofware applicativo (poi, in pratica, ti può creare più problemi che benefici).

Il gestionale di cui ti accennavo utilizzava degli interceptor che intercettavano le operazioni di update e scrivevano su una tabella di audit separata quello che era avvenuto.
Questi interceptor si potevano applicare (o togliere) alle singole entità tramite file di properties. Questo è bene, perchè tramite semplici configurazioni puoi decidere cosa e quando loggare

Le operazioni di lettura non venivano audit-controllate, ma semplicemente loggate su AS. Come hai già intuito questa feature introduce un overhead all'azione di business che è bene tenere basso.

Il tutto dipende ovviamente da quelli che sono i tuoi obiettivi di monitoraggio.