The problem with 'weak' categories is the more flexible you make a subsystem the more ways people will find to abuse it.
I agree, and I think that this is an important area in game development/writing.
Anything written should not be blatant abuse, and if the writer is not on top of it, the Editors, proofreaders and playtesters should fire off flares and make sure it's fixed.
I think there are two important sub topics involved here.
1) "Everything is covered by the rules, and anything not covered by the rules is not allowed."The only time you need to write with the assumption that the GM is a passive, drooling idiot, is if you're writing a computer game where in the end everything has to either be allowed, or disallowed in the Rules-As-Written. For a computer game, the rules have to be perfect, not in the sense of best-ever, but in the sense that all actions have a precise and exact resolution, from which no deviation is allowed.
You need a 90 in climbing and some luck to get in that window, you're not allowed to pile up boxes or go buy a ladder unless someone wrote those choices into the game.
If the GM is assumed to be a living, breathing entity with judgement to make calls, the rules can offer some specific rules, and some general rules. . .The GM has to make the final call on how to apply the rules regardless, so assuming they're not a literalistic drooling idiot CPU seems fair.
2) "What's Abuse in my game is Fun in your game, and vice versa."There's a baseline average to which games are written in general, but your game may be very high powered, and that may be purely due to choices only in the realm of "GM Judgement". . .your game may not break a single rule in the book, but in any instance where the GM has to make the call, you choose to allow rather than disallow, or to make the penalty/modifier lower for a given action. If the rules were written so only my game, with my GMing style were the RAW, and thus your high end game was "abusive" in breaking the rules. . . .that might irritate you. . .it would also tend to make the book a LOT thicker, as rules are written to cover every possible instance the development team can think of, with specific written rulings and modifiers.