BATV needs Transparent Mode

You have to have it on to intercept port 25 traffic.  If not, the original message will not have the BATV cryptographic code added, so return messages will not have this information and BATV will block those messages.
 
Astaro can't make modifications to the way that BATV works as these are standardized by rfc (draft-levine-mass-batv-02 - Bounce Address Tag Validation (BATV) draft-levine-smtp-batv-01 - Bounce Address Tag Validation (BATV)).
 
As with all anti-spam measures, there will be false positives and can be affected by the server on the other end.  It will need to be tuned to your environment.  For example, one customer my company deals with is using an ancient version of sendmail that completely freaks out if it finds a prvs tag and will reject the message outright.  I had to create an exception rule to not apply BATV to any messages send to this customer.
 
As far as whether or not you should use it, you'll have to look to your specific requirements to determine if it would be useful or not.  
 
For me, it catches and stops cold several dozen spoofed replies (which is what it was designed to mitigate) per week, so I find it useful for my environment.

I have seen some issues with BATV being the reason for mail being blocked here as well, and it seems it will be a widespread issue with GroupWise rule generated messages.

By default, GroupWise rule generated replies and forwards come from "postmaster@host.company.com" where the host.company.com is the host name of the GroupWise Internet Agent (so in my case, for example, it would be postmaster@echt.caledonia.net).  Even though GroupWise defines this as the default sender for rule generated messages, it does not automatically make this address a valid address for accepting bounces.  So, BATV fails.

GroupWise does have a switch (/realmailfrom) that can be placed on a GWIA so that all outbound rule generated messages come from the actual mailbox user and not the postmaster user.  This solves the BATV, but of course is not something the Astaro site can control, but is the responsibility of the GroupWise administrator.  I've set it for my site, but my guess is that I've missed a few "out of the office" rules from recipients since I implemented the BATV checking on my ASG (and will continue to miss them since I would have very little reason to check for this generally).

Danita

I have seen some issues with BATV being the reason for mail being blocked here as well, and it seems it will be a widespread issue with GroupWise rule generated messages.

By default, GroupWise rule generated replies and forwards come from "postmaster@host.company.com" where the host.company.com is the host name of the GroupWise Internet Agent (so in my case, for example, it would be postmaster@echt.caledonia.net).  Even though GroupWise defines this as the default sender for rule generated messages, it does not automatically make this address a valid address for accepting bounces.  So, BATV fails.

GroupWise does have a switch (/realmailfrom) that can be placed on a GWIA so that all outbound rule generated messages come from the actual mailbox user and not the postmaster user.  This solves the BATV, but of course is not something the Astaro site can control, but is the responsibility of the GroupWise administrator.  I've set it for my site, but my guess is that I've missed a few "out of the office" rules from recipients since I implemented the BATV checking on my ASG (and will continue to miss them since I would have very little reason to check for this generally).

Danita