In the early gcc-3 era there was probably need for it.
But currently gcc-3.3/3.4 is more stable and many bugs have been fixed.
So, I think that you should check all usages of these commands and remove / make less strict some of them.
For example I can build Gentoo with ~x86 with "-O2 -march=athlon-tbird -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -frename-registers -fno-align-functions -fno-align-labels -fno-align-jumps" flags on several systems and strip most of strip-flags commands from core and other ebuilds and have completly stable system. (-O3 seems to work too)
In gcc-3.4 some new flags are added that make executable much smaller and faster (-funit-at-a-time and others) - see LKML for some tests.
So, unless I am completly wrong, you could _at least_ add USE option to ommit most strip-flags automagically...
Steps to Reproduce:
what works wonderfully for one user really doesnt count much for other users
or for other architectures
Alot of flags like you mentioned are stripped out because invariably, Murphy's law states "What can go wrong, will go wrong", and in alot of cases, it's over-zealous CFLAGS combined with flakey hardware that triggers a number of compile failures on core system packages like glibc/gcc.
To save us from having to wade through dozens of "glibc compile failed" bugs due to such over-zealous CFLAGS usage, we strip most out except for extensively tested (by multiple users/devs across multiple archs) flags. I would not totally rule out several additonal flags being allowed in the future, but it'll have to be discussed, and any such changes monitored closely.