Presumably because addressing it does not meaningfully improve the security of Google's customers and users.
For example, we don't want physical security or the police second-guessing the intent of someone trying to sneak into one of our buildings - so we set a very clear scope for the program, pragmatically focusing on our user-facing applications and excluding things such as attacks on our facilities and corporate infrastructure. It's a broad exclusion, but it's hard to come up with something finer-grained yet clear enough.
In the same vein, we ask researches that they don't go after any systems unless it's perfectly clear that the application is owned and operated by us - for example, because it's in an IP range registered to us. Again, while this may be more limiting than we'd like, it protects the community against overly litigious parties if the system proves to belong to somebody else.
In several unusually serious cases, we have made case-by-case exceptions and have paid external researchers for nominally non-qualifying bugs; but it's a tricky balance, and we use this power very cautiously.
Source: I authored a good chunk of the current rules for Google VRP ;-)
However, this case is different. While it was absolutely an attack on Google's infrastructure, it was discovered through a vulnerable external web service. Even though the control panel application is not a Google product, it stores user passwords in clear text as decoding it seems to be trivially simple. At the very least, Google should be responsible for picking third party vendors that store passwords using one-way hashes ;).
If you ask me, this should be one of those special cases!