Both keyboards would perform absolutely equally for the user-level code. There might be small differences (nano- to micro- seconds on a modern PC) if you write device drivers. If the system hangs, both keyboards wouldn't solve the problem. Go for hard reboot.
Long answer TL;DR;
What is an interrupt?
When hardware (or some critical piece of OS internal software, like kernel) requires a processor service it fires up a message or an interrupt, which requests the processor to postpone whatever it is doing, and handle this request.
How it works?
When hardware generates an interrupt (e.g. a key press), this request goes into an interrupt controller. Controller then immediately interrupts CPU on a single line of its machine code (CPU still executes this last line). Once processor is ready to service this request, it asks an interrupt controller for an Interrupt Request (IRQ) and a handling routine. Interrupt controller has an internal data structure - Interrupt Dispatch Table that contains a pointer to a routine that is supposed to be executed by the CPU for a particular IRQ.
All different interrupts correspond to well-defined limited Interrupt Request Level (IRQL). For example on x86 systems there are 32 IRQLs, and on x64 and IA64 there are actually fewer - 16 IRQLs. Clearly, that there are more hardware devices and software services than IRQLs which means all some system objects will share IRQLs.
IRQLs table for x64
IRQL | Description
15 | High/Profile
14 | Interprocessor interrupt/Power
13 | Clock
12 | Sync
11 | Device N
.. | ...
3 | Device 1
2 | Dispatch/DPC
1 | APC
0 | Passive/Low
Higher IRQL (with larger number) have higher priority. All components of a system try to keep the current IRQL of a processor on the lowest possible level - 0. If a higher level interrupt occurs, then current IRQL level of a processor is raised and the interrupts with lower level will not be handled up until all interrupts with higher levels are resolved. IRQ can be batch-handled if IRQ scheduler is able to queue several IRQs of the same level for processor execution.
What is the point?
This all has been really well designed to separate end-user from the complexities of hardware and make a universal architecture that can work with many types of the hardware/software.
User-level code (i.e. not kernel-level) is only executed when processor is at the Passive/Low (0) IRQL. Point is, you can only handle a key-pressed event in your application after all IRQLs have been handled. Therefore, for a keyboard it doesn't matter what IRQL is assigned to the hardware interrupt.
IRQL are only OS abstractions and are not set in stone. Corresponding IRQ and IRQL are stored in Windows registry (for example), and any enthusiastic user can change them manually.
Quotes from the question
Because USB keyboards rely on a USB generic driver and architecture
that has only access to a few IRQ channels, it cannot give the
keyboard access to an IRQ as priority-high as another (say PS2)
Perhaps the author meant lower IRQL instead of the fewer IRQ channels. Anyways, it doesn't really matter as it is not visible to the user on any modern PC. The possible differences are of the nano- to micro- seconds level and they only happen at the kernel level. In both cases user-level code is blocked by the OS kernel.
Does this (if it is true) mean that USB keyboards would be less
responsive than keyboards plugged onto another port type?
It is not true because of the way OS designed. If OS is busy with something and is "slow", both keyboards would behave identically.
Take for instance a USB keyboard mapped to a medium priority IRQ, on a
faulty system that is stuck on another medium priority interrupt
In this case the system will BSOD, IRQ handling routines must be designed up to a certain standard (such as they must be fast, synchronous, non-blocking so on). Any deviation from this and the kernel will BSOD.
Due to its relatively equal priority, keyboard events would be ignored
and you won't be able to send Ctrl-Alt-del or any other emergency
If the system hangs there are lots of things that can go wrong, but most likely the keystroke IRQL will be handled at the driver level. The problem is, it will not be delivered to the application that subscribed for such notification, as OS is busy doing something else.