Incompetence - nothing to do with performance
I can tell you right now why they pulled the ARMv6 version - because ARMv6 and earlier ARM architectures don't come with automatic transparent unaligned access fixup. ARMv7 devices to. What does this mean, you ask?
Some processors (ARM, SPARC) don't actually work with memory pointers that aren't word aligned. On ARM, that means 4 byte aligned (32-bit). So if you ask it to dereference a pointer, for the sake of the argument, pointing at adress of 6 bytes, it will truncate your pointer to a 4 byte boundary and feed you 2 bytes of garbage at the beginning, and not give you the last two bytes of what you were expecting. This will typically lead to a crash in very short order.
x86 has a transparent automatic fixup for this in hardware, as does ARMv7. But there is a performance penalty to be paid for this. On ARMv5 and ARMv6 under Linux, you can actually enable a kernel level software based fixup for this by doing "echo 2 > /proc/cpu/alignment". But that's even slower than the hardware solution. To see just how crap your software already is, do "cat /proc/cpu/alignment" on your ARMv5/ARMv6 Android phone/slate and you will see just how many such unaligned access violations were detected (they still get detected and counted, it's the fixup that's expensive).
I actually have a Firefox bug filed for an issue like this on normal ARM Linux - not Android, but the nature of the problem is fundamentally the same.
So don't let the developers BS you with performance arguments - that is totally bogus. The reason they can't produce a working version for ARMv5 and ARMv6 is due to x86 induced brain damage that leads to people using horrible practices like casting structs into char[] arrays (hint - char[] get byte aligned by GCC, so when you end up dereferencing an element in it, you get garbage).
And if you think that's bad - I also have a similar bug filed against e2fsprogs (yes - the thing that the integrity of your file system depends on - now fscking your file system means something other than you would hope).
On SPARC this is solved by the compiler aligning everything correctly, but ARM has traditionally been the platform for competent programmers working with very tight memory, and aligning everything to a 4 byte boundary means wasting a few bytes of memory - which you may not have on your SoC (an extra £1 for a bigger SoC times 1M units adds up to enough to justify spending an extra man-year on squeezing the code into a bit less RAM).
Then again, a web browser requiring 512MB of RAM _without flash_ says something about developer competence in itself - compared to that, the sort of bad practice that leads to unaligned accesses is small potatoes.