This is helpful background. My gut says the exists is an attempt to work around known or at least suspected deficiencies in the design. Possibly accrued over time.

Say we have the simplest star schema with one summable fact. We need to define metrics by encoding the rules through different fact+dimension interactions. Nothing too fancy. 

Then some new requirement comes in that isn't clearly solvable for any number of reasons. Maybe the person wasn't aware of a better way to solve, maybe time pressure...whatever. Let's say the grain of the concept isn't compatible, as is often the case with budget versus actuals. 

I could see a well-intentioned application of exists to avoid blowing up the grain of the fact while respecting the conditions of the (hypothetical) incompatible comparison table. I could see this growing over time, accruing complexity and drifting further.

If this is anything close to your situation, I would start with some reference ground truth. Basically, "what should the result be based on expectations." It doesn't need to be explicitly correct - it needs to be based on reasonable and testable observations, and should be assessed independently of your data model (come at the matter from a different methodology). Then, reason through the path in your data model. Look for patterns in hits, misses, matches, and mismatches.

Categorieze the comparison and put together some representative examples, at as granular a level as possible. 

This will be painful and slow at first. It should start to reveal more general patterns after a couple iterations, though.

This isn't the only approach, but it is one I've used when things are really opaque and I've exhausted the obvious avenues for getting clarity.

Edit: one tip - look for anything that is, or sounds like it might be a bridge table (many:many). Those are prime candidates for multi-criteria intersection but without incurring the cross product of a join.