kernel documentation says:
" We try to grab the console_lock. If we succeed, it's easy - we log the output and call the console drivers. If we fail to get the semaphore, we place the output into the log buffer and return. The current holder of the console_sem will notice the new output in console_unlock(); and will send it to the consoles before releasing the lock."

Updating log buffer should not be high latency operation. However, flushing to console would have high latency based on how fast is console device. Is this the reason why cpu is throttled ? Anything else ?

From printk implementation, I see that while updating log buffer and flushing to console, local irqs are disabled and spin lock is held. This means that if flushing operation is slow(console device is slow), preemption and interrupts would be disabled for longer time making the system sluggish.
Does this seam to be fair explanation of the question in hand ?