More precisely, it's the compiler (or luckless .asm hacker) that suffers from register starvation. Register renaming can avoid pipeline blockage but if the compiler thinks it's out of registers, it'll use... wait for it... memory accesses. Now you've entered the wonderful world of load/store penalties and the like, and at least some of those cache lines that the Mozilla folks wanted to preserve are going to get used anyway.
It's really a pretty terrible idea for Mozilla to favor 32-bit code over 64-bit code these days. Not so much because of any feature or perf differences, but because it signals that they don't really have a clue what they are doing.
As a lucky asm hacker and frequent advisor to compiler codgen engineers, in the past few years re-order engines have gotten to be wide enough that it's really not too bad. It simply requires a different mindset; instead of attempting to hand-schedule individual instructions, one instead schedules small blocks of instructions chosen to minimize state that must be preserved across block boundaries (to minimize register usage between blocks) and lets the rename/reorder do their work.
There are some (mostly numeric -- hand-tuned FFTs come to mind) codes for which the lack of names really does cause difficulty, but they are relatively few and far between.
All that aside, yes, 8 GPR names is just absurd, and targeting x86_32 is ridiculous when x86_64 is so widely supported.
It's really a pretty terrible idea for Mozilla to favor 32-bit code over 64-bit code these days. Not so much because of any feature or perf differences, but because it signals that they don't really have a clue what they are doing.