Eh, it's not exactly the same. Videocore is pretty unlike most GPUs, its a proprietary DSP architecture and has been sold as a standalone only processor in many devices— I was a little surprised to see people start calling it a "GPU". The design differences mean that general GPU reverse engineering work is unlikely to be that useful against the PI's chip. For the rPi the device boots from the videocore and you must have a rather gigantic binary blob just to get the kernel loaded on the arm, even if you're not using video out.
AFAIK on most arm single board computers with proprietary GPUs if you're not using the video out you don't need any proprietary gpu code.
A closer comparison would be the TMS320C64x+ in some of the omap4 chips. It is also used for video decode with blobby codecs, but in its case there is an open toolchain, public specifications, (resulting in a) nice Theora port to it, and you still don't boot via it. (Though it isn't also used as the system's general GPU)
> It may be slower than the latest tablets but that still makes it as fast as a desktop PC of 10-15 years ago, which I recall being more than adequate for most applications.
Ah, well it's slower than many think even by that comparison— the machines you are comparing it to weren't driving 1080p displays, decoding realtime, compressed media, running N layers of inefficient interpreted code. Some of the expectations are different, and I've personally had some frustration where people showed up trying to get my software running on Pis— software which is many times realtime on faster arm SBCs— frustrated and having a hard time.
There is certainly a place for slow low power machines and having some more pressure against unnecessary bloat is great, but I think the gap (esp in terms of awareness) in options between quite-slow at $30 and a dozen times faster at $150 seems to be pushing people to Pi when their needs really require something a bit faster and could tolerate a slightly higher price point.