After some thinking I don't think so this design is not good. It changing a working with exception (error) levels - and it is not consistent with other PostgreSQL parts.
A benefit is less than not clean configuration. Better to solve similar issues via specialized plpgsql extensions or try to help me push plpgsql_check_function to core. It can be a best holder for this and similar checks.
You first should to say, what is warning and why it is only warning and not error.
Personally, I'm a huge fan of the computer telling me that I might have made a mistake. But on the other hand, I also really hate it when the computer gets in my way when I'm trying to test something quickly and making these mistakes on purpose. Warnings are really good for that: hard to ignore (YMMV) accidentally, but easy to spot when developing.
As to how we would categorize these checks between warnings and errors.. I can't really answer that. I'm tempted to say "anything that is an error now is an error, any additional checks we might add are warnings", but that's effectively just freezing the definition at an arbitrary point in time.
And why plpgsql warning processing should be different than general postgresql processing?
What do you mean? We're adding extra checks on *top* of the normal "this is clearly an error" conditions. PostgreSQL in general doesn't really do that. Consider:
SELECT * FROM foo WHERE fooid IN (SELECT fooid FROM bar);
where the table "bar" doesn't have a column "fooid". That's a perfectly valid query, but it almost certainly doesn't do what you would want. Personally I'd like to see a WARNING here normally, but I've eventually learned to live with this caveat. I'm hoping that in PL/PgSQL we could at least solve some of the most annoying pitfalls.
My objection is against too general option. Every option shoudl to do one clean thing.
It looks to me like the GUC *is* doing only one thing. "list of warnings I want to see", or the shorthand "all" for convenience.
