The fundamental issue with bulk operations (regardless of source) is there is no knowledge of prior row state before the bulk statement is executed unlike all other operations and how Envers interacts with Hibernate's Session & Event subsystems.

As you indicated in an earlier comment, such a solution would involve Hibernate/Envers fetching state for each eligible row prior to executing the bulk operation. It isn't as simple as selecting the primary keys based on the supplied predicate clauses as Envers stores audit history in different ways depending on user chosen global settings, audit strategy, and operation being performed. Furthermore, I'd be concerned that any solution like this would be equally or at least comparatively as slow as the code you were concerned about above, particularly when the volume of rows in question is significant.

Long-term, could support be added to abstract this away from users, absolutely.

But just because something can be done a specific way doesn't necessarily mean that is the right and most efficient, appropriate way. It's like trying to argue that one can use a stateful Hibernate session to bulk insert data. It's doable, but is that the right tool for large volumes of data? This is why Steve was implying database constructs, such as triggers or even a stored procedure, may be a better route from a sheer performance perspective.