The wiki itself also uses data items in a few places besides the infoboxes. For example, if you search for a key that doesn’t have documentation yet but does have a data item, the search results page generates an infobox based on the data item. If you try to access the key description page for an undocumented compound key, such as inscription:haw=*, the 404 message describes each part of the key.
In the wiki’s article namespace, we typically see something less clear-cut. Rather than vandalism, it’s usually an edit that’s plausible but needs broader discussion. Unfortunately, inexperienced mappers sometimes get the impression that changing the wording of the wiki will magically cause the database to change en masse. Much more experienced mappers sometimes suffer bouts of overconfidence as well. I myself sometimes get caught off-guard thinking something is uncontroversial when of course it’s controversial, because OSM.
I agree that this problem isn’t specific to data items, but it does compound with the problem of overzealous mapping for the QA tool. One potential mitigation is to keep data item–based validation checks separate from the usual checks, or in an entirely separate tool. Sophox can even help you spin up an ad hoc QA tool based on data items, with a level of effort akin to writing an Overpass query.
Specialized QA tools, such as this boundary tagging consistency validator, could use similar federated queries to expand coverage beyond the scenarios that they’re currently designed for. They aren’t as tightly integrated with editors, so there’s an opportunity to frame the warnings so that mappers approach them with more nuance.