IMHO it will only have an effect on latency if the ACK traffic eats a significant portion of the respective link's bandwidth. As @dlakelan noted on very asymmetric links it can help in the slower direction. It also makes some modicum of sense for very bursty links (like DOCSIS) as they will typically collect a number of ACKs and basically send them out back-to-back in one burst. In that case the receiver will most likely get all these ACKs back-to-back as well; and it effectively it is only the last ACK that carries useful information for progress of that TCP flow. I doubt that on the faster ingress direction this is going to help as the ACK packets that could be "merged" already passed the true bottleneck so they already delayed other packets....
Now, the Linux kernel developers consider the traditional ACK-every-two-full-MTU packets rule as quite wasteful at modern bandwidth and actually implemented methods to reduce the number of ACKs directly in the sending kernel (and I also note that aggregation techniques like GSO/GRO will also reduce the ACK load).
IMHO, trying to reduce the ACK frequency is a valid point for the endpoints, but I have a bad feeling if middle-boxes like a router start to pretend they know better than the endpoints, so I tend to not use ACK-filtering myself. But my 50/10 link is not too asymmetric and also not bursty enough, if any of this would be different I would reconsider this and at least bench-mark ack-filtering.
ACK-filtering should have no effect on that. In the worst case a traditional sender will not be happy with non-traditional ACKs and migt actually send at a lower bandwidth than possible (but this would also apply to the ACK-thinning resulting from GRO, so this is quite unlikely).
Tl;dr: I do not expect noticeable improvements for the OP by enabling ack-filtering, but he can sure try, I might well be wrong.
Hope that helps