I apologize in advance for the long and technical posts that are about to ensue. Some of this I have brought up in the past. If you don't care about these types of things, feel free to stop reading now

So, when the keyboard is idle, no interrupts are generated and no processing is required by the pass through. It is not polled at all.
Ok, I'm not going to state that there is always functional speed impact on a
well implemented pass-through, but I do know a thing or two about the Cypress CY7C63413 Microcontroller. You state that the IPAC "Does not use a scanning method which causes a variable delay" and is "interrupt driven" so the following must apply. I won't even go into why it's impossible to know what is happening on the inputs without "scanning" or why scanning can actually be as fast (or faster) and uniform in speed. But we can if you would like.
One very important thing to understand when considering how these chips function is that the GPIO (General Purpose Input / Output) interrupt is a single interrupt linked to all inputs set to trigger it. On a device setup to be "interrupt" driven on it's inputs, all inputs would be set to trigger the GPIO interrupt. That means that when the interrupt is triggered, the only way to know if it was the keyboard clock line that triggered it, rather than one of the other inputs, is to specifically examine that bit for activity. It would do this any time a button was pressed, a joystick was moved, etc. Every time,
without exception.
From the datasheet:
------
GPIO Interrupt
Each of the 32 GPIO pins can generate an interrupt, if enabled. The interrupt polarity can be programmed for each GPIO port as part of the GPIO configuration. All of the GPIO pins share a single interrupt vector, which means the firmware will need to read the GPIO ports with enabled interrupts to determine which pin or pins caused an interrupt.
------
So it would be
inaccurate to state that a "pass-through" does not use
any clock cycles when not triggered. It's status is checked every time the GPIO interrupt is triggered, otherwise it cannot know what exactly caused the interrupt. One could even accurately state that all inputs are "scanned" whenever one of them is pulled low (button press, etc.), and that's only if the interrupts are not disabled due to another interrupt driven service being acted upon at that moment. Microcontrollers can only use the CPU for one thing at a time, period, interrupt driven or not.
Furthermore, clocking in bits from the keyboard (or other serial devices) is very timing sensitive, so interrupts which would normally be generated by GPIO ports would be held off. If the same method were used in daisy chaining controllers, or used internally on a 4-player controller between microcontrollers, one would always be held off while another was being serviced. Very messy and not the most efficient approach, which is another reason I don't support it.
As an aside, Pass-through ports are pretty much moot nowadays. USB keyboards are cheap, they don't impact the encoder used
at all, and work very happily alongside KeyWiz's, IPAC's, etc...
Its easy to see from a picture of the Keywiz that it uses the same chip (although they seem to sand off the part numbers on their chips for some strange reason) but its a different animal of course, different coding.
As for why we take the numbers off of the chips, it's spelled out in this very thread. Laypersons aren't fully up to speed with the concept that a microcontroller is a "brick" without the code that gives it life / purpose. Those same individuals often believe that chips which can be purchased at the local "electronics hut" have only the value of the purchase price, but without understanding how they work, the value of the software is not considered. Much like saying the media for the latest PS3 game costs less than a dollar, why do the games cost sixty? By removing identifying markings, the foundation for that incorrect assumption is removed. BTW, it's a very common practice, especially for "caseless" products.
Is there anything else I can clear up for you regarding GGG's practices?

RandyT