It's saying, after you've classified the bugs, you're not to do any other work until the bug list is cleared. This will lead you to zero-bugs (of the known ones of course).
I've implemented and seen this first-hand in 4 different companies.
Let me word it differently.
You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid.
The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is.
"Web font is being downloaded when it should be embedded in the app" is clearly a bug, by the normal definition of bug.
This system classifies by priority to get Critical/"Bug"/Other, and it further divides the lowest priority into new features vs. changing features. At no point does it ask if something is a mistake. It doesn't care. So it shouldn't use the word 'bug'. It tricks people into thinking it's something it's not.
If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug.
Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what.
So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.
I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs.
I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)