Why pass debugging, warning and optimization flags to downstream consumers?

Looking at this, from a trunk build:

$ tail -1 apr.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -I${includedir}
$ ./apr-2-config --cflags
  -g -O2


or from APR installed by Homebrew on macOS:

$ /opt/homebrew/opt/apr/bin/apr-1-config --cflags
  -g -O2 -Wall
$ tail -1 /opt/homebrew/opt/apr/lib/pkgconfig/apr-1.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -Wall -I${includedir}


(note that MacPorts evidently takes the trouble to remove those flags 
from the results.)

Why? Why are we telling our library consumers about debugging, 
optimisation and warning flags? This makes no sense to me and is 
actively detrimental. In Serf, for example, we go through extra hoops to 
remove this crud from the APR flags; and I believe Subversion does 
something similar. APR should not dictate how its consumers are 
compiled. The --cppflags, sure, those are necessary on some platforms in 
order to make the resulting linked code work; but --cflags?

The culprit seems to be our construction of CFLAGS, then copying them 
wholesale to EXTRA_CFLAGS, which then get interpolated into the 
pkg-config file and the apr-X-config scripts. What, exactly, is the 
point of that interpolation? If it's to pass flags that were set 
explicitly at configure or build time, then that clearly is not how its 
implemented, because setting CFLAGS for configure removes them from 
apr-X-config and the pkg-config file.

My knee-jerk reaction was to just stop interpolating EXTRA_CFLAGS, but 
then, I've no clue what that would break. Someone with a deeper 
understanding of the autotools build, please speak up. I'm happy to dig 
into the build code to get this fixed, but I would appreciate a place to 
start; not just on trunk but the 1.7 and 1.8 branches, too.

-- Brane