The point of using interrupts on switch edges is to remove the issues of bounce. Sure, go ahead and implement the filters but the code should get the right answer anyway.
Switch bounce is only going to be solved if your application code handles it - that's not something inherent that comes with interrupts.
A person could have just as many (or even more) switch bounce problems with interrupts as with polling - it's all in what happens in your ISR, and what your application does when it detects a change.
For example, say I have an application that sends a text message to a mobile phone on each change of position of the rotary encoder, indicating which direction, clockwise or counter-clockwise, it was rotated.
An interrupt handler that dutifully responds to signal edges might queue up a flurry of "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" messages during the bouncing. Sure it "got the right answer" at the end - a net change of +1 direction step - but the
behavior was not at all what was expected - actual debouncing was still needed.