Timequest question using gated clocks

Your paths easily meet setup, so I don't think that's the problem. I would also check hold, especially in the fast corner. There may be a logical issue, i.e. if you have 3 registers on slow_clk and slow_data path, I hope slow_clk is supposed to transition long after slow_data_path has settled, as their sources are asynchronous and you can guarantee what cycle they get a value. As buzmeg says, I would not have a signal like filt_resync be used as a clock. It's not meant to be a clock, and should probably be an enable or something. And it doesn't hurt your power or anything, since your base signal is already on a global.

As for Quartus sucking, I've actually found it pretty good. The problem tends to be pretty difficult though. For example, I put a 10ns hold requirement on a 20ns clock, and it couldn't meet timing. That's because it needed to meet across all timing models, and so a 10ns delay in the fast corner can be longer than 20ns in the slow. I ended up changing the clock to 40ns(it was just an experiment), and the router successfully added ~20ns of delay in the slow corner, which met the 10ns requirement in the fast corner. It basically routed once around the chip to do this. When you have lots of paths crossing domains with clock skew, and if the setup requirement is tight, this can blow up. If the setup requirement isn't tight, it can add a lot of routing, which wastes valuable resources and power.

I do agree the on-die variation in the timing models sucks, although everything I hear is that it's real. But it absolutely kills timing between domains, and makes the fitter look bad. In the end, going with an enable is usually much better, as you're fighting something FPGAs aren't designed for. (I have seen designs that required gated clocks, and implement more than 30 in a single design, but it's not fun).