I've been in environments where it worked just fine. Bug fixes (and exceptions = bug fix) always took priority over features. And yet not only did we never get delayed, we routinely were ahead of schedule.
As the article points out, the trick is to get it into your blood -at the start-. If it feels like fixing exceptions takes all your time it's probably because you have let a lot of them creep in.
How many known exceptions do you introduce per sprint? It should be zero; nothing new that you're writing should be creating an exception, that isn't fixed in the sprint.
So what's left? Exceptions that are uncovered outside of the sprint. That is, you had a feature written, tests for it written, QA test it, client demos show it off, and any exception you saw you fixed already. So outside of all of that, where can exceptions even occur? Well, after release, obviously. Weird race conditions, deviations off the critical path, users doing unexpected things, etc. But the frequency of those should be pretty low. Maybe one, two a sprint, max? Surely you can take the time to dig in and fix those without causing the sprint to slip.
Now, as the article also mentions, when you start getting a huge, complex codebase (either due to time, or team size), this gets harder. More complexity = more edge cases. That's one of the reasons to reduce complexity wherever possible, to isolate functionality as much as possible. And this also assumes you have a development process that has you delivering every sprint, and having the stuff used. If you're doing some waterfall "we'll code like crazy for the next year, then test, then deliver", yeah, you probably can't do it. You already said the feature was done; no time to fix that bug! Sorry.