Practically this means that the Linaro tool chain won't double the performance of this test on a fuller environment.
Additionally it's fairly specious to say 'double' the performance, on Android things are typically vsync'd and double buffered so if you render at < 60fps you will degrade to 30fps.
IMO this is mildly disingenuous or at best naive and from a technical perspective Linaro should really do a better job trying to make their efforts relevant.
They'd be better off showing off improvements in browser performance because the CPU is still used for some 2D rendering.
Take a look at /system/lib/egl/egl.cfg
In many cases where I've looked (though it varies on device) the software renderer does get picked up. If you remove the entry for the software renderer, it often speeds up in general, because hardware is forced to be used.
I read the article and watched a few minutes of the video and there was no detailed answer. The article itself didn't seem to link to any detailed resource either.
(Double-buffering isn't particularly relevant to FPS that I can see. It just prevents you seeing the frame while it's being drawn, in practice it's mostly useful for reducing flicker from overdraw.)
I'll add that usually you don't see a constant rate of rendering performance. Render time for a frame wanders above or below 16.67ms (with the design target being under that, if 60fps is the aim) depending on complexity or how busy other tasks are. It's not usually the case that every frame takes 22ms (i.e. 45fps) to produce; so it would be very unusual to see a game / app flip from 60fps straight to a locked 30fps. Rather, the odd frame will take slightly more than 16.666, with most falling under. The statistical distribution will give an FPS rate somewhere between 30 and 60.