Having allow_rasterization manage whether the function decorated with it would actually do something would be confusing, simply because there is no way of judging on that behaviour from its name.

Using a check_visibility_and_allow_rasterization decorator will lead to the need of a check_visibility_and_dont_allow_rasterization as well, which creates an unnecessary double structure.

An additional and independent decorator check_visibility may be an option, but is it really good style to defer a check like this to a decorator? Also the net gain would be to replace two lines

if not self.get_visible():
    return

by a single line

@check_visible

One would also need to make sure different draw methods do not use some more sophisticated and/or more individualized logic, in which case at least part of the logic still needs to exist in the draw method itself.

Readability matters; and I feel like in this case the benefits of using a decorator are too low to sacrifice readablity.

I think this would be different if a performance gain was to be expected from using a decorator. But I don't see that to be the case.

Well, the point above is that the first case I found of not checking visibility is a bug (quiverkey), and I'd be puzzled if there were cases where we really don't want to check it -- just like not allowing rasterization for 3D artists was an oversight (#10013).
Having a single decorator to apply around draw() would make this less likely to be forgotten. I agree that splitting into a second decorator mostly defeats the purpose of the proposal.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Let's just track the actual visibility bug at #25890.