This wasn't the case last I checked (with x264), especially if you consider video quality. Historically VP8 has been much slower, mostly because existing H.264 tools have had more time to mature.
I assume they mean power to decode, which makes sense if the article talks about decoding 10 other chat participant's video streams.
I also believe, based on stuff discussed regarding WebRTC that some H.264 advantages don't apply in realtime encoding, like B-frames and so it's a much closer comparison than encoding a movie for streaming. The various submissions to the IETF mailing list arguing for one or the other on technical merit basically came down to a tie.
I wrote one of the first de/packetizers for VP8 RTP back when the spec was released. My impression was that the codec isn't really designed for network transmission. The probability table for the entire frame is sent up-front, so any loss of that makes the entire frame undecodable, and there's no slicing/IDR or NAL-like layer. It's fairly unworkable without a reliability or error-correction layer on top.
More competition in the codec space is a very good thing, but VP8 is a relatively weak entry IMO.
> My impression was that the codec isn't really designed for network transmission
That seems unlikely since the major user of its predecessor VP7 was Skype (and before that VP6 was the "web codec" in Flash for a while). Maybe you could make a case that it has flaws that could make it better for this, but it seems silly to claim it was designed for a different use-case.
VP6 in Flash was always delivered losslessly over TCP, and never used for video capture in Flash. Skype is what makes VP8's shortcomings (for video chat) even more interesting, but On2's codecs show a very clear evolutionary path even from VP3. My guess is they didn't want to deviate too much from what was tried-and-true.
Doesn't change my opinion, though -- I think it's more the case of "Well, this works well enough for video chat, if you also do this and that" rather than "We designed this from the ground-up for low-latency, unreliable operation."
