Don't be sorry that is for sure.. Just one of those things we are not in total agreement on.. Most of the time I am right with you on everything..
But in this instance while you think its sloppy and lazy, I see it as extra rules for no reason ;) heheeh
Reject is a good reason to do that sort of rule - this for sure I will agree with. But I have found that end users are not looking at sniffs to figure out why something is not working to reject while it might speed up an error in the end application vs waiting for tcp timeout after retrans, etc. Rejects don't always solve the issue. And then again if you got some application that is banging at your door.. Why do the extra work of a reject, etc.
if I wanted the reject or a log then sure I would do the explicit, but vs the any I would do an allow ! rfc1918. To me this is the rule closest I can get to the actual rule I want. I don't want a allow any rule. I want an allow to NOT rfc1918 address ;)
If your not doing the reject or a log.. Then your block rule and then allow takes two rules. While my way accomplishes the same thing with 1 rule - where you say sloppy and lazy I say elegant and efficient - hehe