Comment 1 for bug 585793

And thanks again for bug.
I have some thoughts about this.
First, I guess that your hardware has a couple CPUs, right? (so looks like battery-status asking password for each CPU, because unlike cpufreq-applet, battery-status changes frequency scaling not only for first/primary CPU, but for other(s) also).
Second, the point is that when battery-status handle frequency scaling, battery-status doesn't handle rights/permissions/policies and other such stuff - it just ask cpufreq for switching frequency; what's going on next - depends on environment.
For example, in Ubuntu cpufreq-applet not asking password (by default). But if you don't want to input password anymore, there is (at least) two ways (easy way and correct way):
easy way - make /usr/bin/cpufreq-selector binary suid'able by command
# chmod +s /usr/bin/cpufreq-selector
but as you probably know suidable binaries should be as less as possible in system.
So correct way - configure PolicyKit for permit your user to change frequency:

# cat /var/lib/polkit-1/localauthority/50-local.d/org.gnome.cpufreqselector.pkla
[org.gnome.cpufreqselector]
Identity=unix-user:put_your_login_name_here
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes

So, it's not a bug actually, but I agree that such behavior can be pretty annoying.
I guess that I just should add advice about PolicyKit in a FAQ.
Now, please, try a trick with PolicyKit and let me know, if there is still exists some problems with passwords and authentication.