That's not true either, at least not according to the datasheets. Besides, they clearly intended to give the impression that the Cobalt uses less power than the Red. Why else would they have mentioned it at all?
There are no 'specs' for any of them. Audioqest never publishes any. Just some esoteric mumbo-jumbo. So no specs means no specs can be violated. I don't like that neither. Nowadays even every Chinese company publishes full specs, but Audioquest does not. And I agree, the impression they made with that talk about the MCU (that almost no consumer knows anything about or cares about) is probably intended. But well, that's marketing...
Who in the world does care what the speed of MCU is, if the only thing it's doing is taking USB stream in and sending this into the DAC? Whether it's 33% or 333% faster - who cares as long as it's fast enough? There is no post processing happening, it's not doing any fancy DSP stuff... Just marketing mumbo-jumbo.
Actually I do know why they rave about it as at that time I did some research to find out why the hell they wanted to change the MCU.
Apparently, according to Gordon Rankin, DFC is operating on USB in a High-Speed-Mode, vs. DFR in Full-Speed-Mode.
High-Speed-Mode needs A LOT more power just for the USB, as it allows transfer rates of up to 480 Mbps vs 12 Mbps in Full-Speed-Mode, has shorter latencies, more complicated packet structure and so on.
So, the question is: WHY?
At it's highest rate, DFC can work at 96/24, which means around 4.6 Mbps in terms of a data stream. This is almost 3 times less, than Full-Speed-Mode would allow to transmit. My conclusion is, Audio Quest must be planning to make higher sampling rates available, up to 384 Ksps, which indeed would require High-Speed-Mode. Probably later on with a FW update. But maybe that will never happen, no one knows.
Some years ago, before DFC has been released, people were asking Gordon, whether there will be a FW update for DFR/DFB to make them 384 Ksps-capable. At that time, he replied, don't hold your breath, as the HW is just not capable of processing 384ksps via USB.
Obviously, the new requirement for DFC was, to make this option possible for the future. The new HW definitively can do this, the USB protocol used now on DFC already would allow it, it is just a matter of switching this on. I guess they reserved this option for a later point of time in the life cycle of DFC...