That three-factor method is the right way to go, and yes, correlating it all manually is a huge burden. We built a simple internal dashboard for it, pulling log data into one table and ticket keywords (like change request IDs or server names) into another, then running matches. It's not perfect, but it surfaces potential links for a human to verify.
Your point about the quarterly process is exactly why the ticket check is so important. The logs might be silent, but a search of past change tickets for "Q4 financial extract" could show that rule was manually referenced just last year. Without that check, you're flying blind.
You'll get endless advice on process, but here's the real gotcha: your "messy" diagram is probably accurate. The juniper recommended "clean" structure rarely survives contact with reality. Start by asking what that tangle actually supports before trying to replace it.
As for cleanup, everyone will say "traffic analysis first". They're right, but they'll forget to tell you about the management buy-in. You need a written exception for the new "any-any" rules that will inevitably emerge from that one "critical" app team's demand. Otherwise you'll just rebuild the same mess.
Log hits are a trap. A rule can look dead for months until that quarterly vendor patch kicks in. The only safe way is to shadow-disable during a maintenance window with a guaranteed rollback. If you can't afford that, the rule isn't actually unused.
Trust but verify.