Audit tables should also be declared as entity and can be plugged in the entities where ever it is required.

Isn't that precisely what the @Audited annotation does today, takes an entity you've defined and makes an audit table based on the annotation configuration you specify? In other words, it takes an entity which you plugged into ORM and extends it with change management functionality.

Right not we could create a customized revision entity class by providing some custom revision listeners.

That is because the revision entity is a special case that often does warrant extension. Some business owners need to track additional information such as the person who made the change and an reason why the change was made for audit purposes. Since more than one entity can be audited in a single session transaction, it made sense to track this information in this entity since it would be shared across all entities that are modified within that transaction.

The same thing should and design should be provided to declare audit entities as well.

What information would make sense to capture on a per-entity basis that wouldn't make sense to store at the revision entity level?

If you could provide us more detail on what the end goal is here, perhaps we can look into it, but it's impossible to gauge any action without more from you.