When ValidityAuditStrategy.perform() handles a MOD or DEL (and, in HHH-8280, an ADD too), it needs to find the last audit entry for this entity and update its revision end. This lookup is done via query, so naturally, the persistence context must be flushed, so that the query picks up any changes that aren't yet in the database. This happens in autoFlushIfRequired().
Anyway, this state of affairs can lead to an obscene number of flushes when the number of changes in this committed transaction is high. Database latency and Hibernate dirty checking can make flushes expensive, so it's in our interest to minimize them where possible.
In this case, I don't see why a flush on every perform() is necessary. A single flush separating the session's real work from the audited work should be sufficient, because neither the new audit entries nor the new revision will factor into the query issued by perform(). That query is only interested in looking up audit entries belonging to past revisions.
Without such an optimization, the validity audit strategy issues tons of flushes. In my application, I commit one transaction with low thousands of changes to entities. With the default strategy, I see 46 flushes. With validity, I see 6160.