1. GCJFLAGS should be added to /etc/make.conf the same way CXXFLAGS is.
2. GCJFLAGS should probably be treated as CFLAGS and CXXFLAGS in (for example) gcc ebuild (= it should be striped if CFLAGS is striped)
Steps to Reproduce:
no other packages than gcc uses GCJFLAGS
But still you may want to compile gcj java lib with some optimizations and to do this you need to set GCJFLAGS... More and more people will use gcj as it is (and its libs) maturing and standard or none optimization will make the core libs painfully slow for them and they will not even know why. This is suprise for people thinking that they set optimization flags for gcc in make.conf.
And I set GCJFLAGS manually and noticed that it is not striped as CFLAGS and CXXFLAGS is - it is funny...
And oneday somebody will add (for example) eclipse with gcj to portage (or add use option to compile it with gcj - it is possible now) and gcj will need GCJFLAGS or use default optimizations...
You can set GCJFLAGS in /etc/make.conf if you wish and they will be used if the package's configure script, makefile or whatever detects them.
Essentially, this isn't a portage bug. Whether GCJFLAGS is used and if/how they should be stripped is up to each ebuild. If it is seen that a unified method of stripping GCJFLAGS is needed, it will be added to the flag-o-matic eclass.
As Jason said, you can already set it in make.conf if you want it. I don't see any benefit by adding it to the default make.conf at the moment, maybe at a later point. Stripping CFLAGS isn't related to portage but each ebuild and the flag-o-matic eclass.
Closing as WONTFIX as nobody else has requested this so far, so seems rather irrelevant.