I'll try to answer directly to OP's questions.
First thing to note is that you accidentally mixed two different things, because of similar naming. There are two different things named "design".
There is "design" in the sense of "structure", "organization". That's what one means when talking of "modular design", "streamlined design", "exception-based design" etc. There is also "design" meaning "methodology", "design process", "approach to creating something". What the article described is "design" in this sense, as is "iterative design", for example.
I'm not sure what meaning of design you're interested in, so I'll write a little on both.
No matter what design methodology is used, the most important thing is a clear goal. When designing an RPG game, it's good to know:
- Who the target group is? Who will play the game?
- How is it to be played?
- What kind of experience is it to produce? What it is about, really?
When the goal is known, all parts of the game may be investigated in correct context. The designers may ask themselves:
- What in this game makes it better in achieving our goal than other games in the market?
- How every part of the game empowers what it is about? How it produces the intended experience? How it helps and encourages players to play in the intended way?
- Are there any parts that go against the goal? Are there any that miss the target and water the game down?
The last question is what the article talks about. One may put a lot of things in a game - and increasing number of options seems a great thing at first sight. But it really helps the game if it is focused. Decide what the goal is and prune all that does not help in achieving it.
That's what indie game designers have been doing for years now. The games are focused - and that makes them much shorter, easier to learn and more powerful in delivering the experience than extensive, generic RPGs. Also, they rarely suffer from "sacred cows" and decades-old design artifacts that plague more mainstream RPGs like WoD, D&D etc.
The problematic part is finding what the goal is and putting it in clear words. I saw a lot of games that were doomed to failure from the first day. Their common feature was that they all used "Power 19" or similar questionnaire approach for detailing the design goals - but the answers given were extremely vague. In general, if a "mission statement" for a game contains such buzzwords as "adventurers", "realism" or "fun" (that get used a lot, but nobody really knows what they mean), it leads to nowhere.
The best way of finding what one really wants from a game is playing it. Think for a moment about what you want, throw together a game in few hours (take a system from a game you know, describe the setting and style in two pages of text), get some players and play it. See what you like and what you don't, see where it diverges from your vision and where it hits the target you couldn't even put in words before. Add some pieces, remove some, repeat the process. Don't spend weeks detailing the game world or the mechanics until your vision and design goal are crystal clear.
What I suggest here is an analog of "agile development" in software engineering. Keep it changing until you get what you really want. Don't get too attached to any ideas, because you may find better solutions later on. Don't give your game a structure that will make future changes difficult.
Now let's move to the other meaning of "design". There are several documents and wikis available on the net that list common RPG design patterns, so I won't list all those I remember. Instead, I'll write about a few things that I find really important.
1. Transparent design.
Giving not only rules, but also explanations of why they are there and what is their intended use. It makes the game much more intuitive in use and allows for rulings that are true to the game's spirit instead of being arbitrary. Also, explaining designer intent makes it clear which rules or setting aspects may be modified without problems and which cannot without a lot of unintended consequences.
2. Resolution scalability.
In other words, allowing players to decide what level of (mechanical) detail they want to have in resolution of given situation and giving rules to use it consistently in game, without any need for handwaving. Burning Wheel is a good example - you may resolve a combat at three levels of detail, from a single roll to a tactical approach with action scripts, maneuvers etc.
3. Well-defined abstraction
Every game will use abstractions, there is no way of avoiding that. But the game needs to be clear about what is abstracted and what is not. Doing it well really help player creativity and initiative; doing it wrong leads to a lot of interpretative issues and conflicts at the table. Of course, even worse than not defining boundaries of abstraction is defining them and then contradicting it in the rules.
A few examples:
- HPs abstracted as "you don't really get hit until they are gone, and then a single hit drops you" are fine. Having "cure wounds" spell that restores HP and injury poisons that affect you when you're at positive HP breaks it.
- Movement abstracted to positions on grid is fine. Movement abstracted to purely narrative one is as good. Grid-based movement that disallows sensible actions because characters fill entire grid squares, or narrative one that precisely measures combat speed, are asking for troubles.
- Delegating all inter-character social interactions to freeform roleplaying is fine. Abstract social conflict system with negotiable stakes, or some kind of personality model that makes important matters safe while allowing others to be affected and changed by interactions is fine, too. Social mechanics that is so vague that GM's interpretation makes it either useless or overpowered is not.
4. System tied to imagined world
This one is closely connected with the previous one. It is possible (and, unfortunately, quite frequent) to design abstracted system in such a way that only mechanical decisions affect anything, while whatever happens in fiction is reduced to "flavor text". It turns an RPG into a board game. To design a good RPG one needs to remember that the mechanics (no matter how tactical, balanced and fun) is there to resolve situations in the fiction and must be shaped by them.
A good example of this piece of design is Dogs in the Vineyard. Mechanics is extremely abstract, just bidding match with dice. What makes it fun is that not only the final result of a conflict matters in fiction, but every single action may be significant. It also brings us back to point 1: without the authorial explanation of how the game is intended to be played, it would easily devolve into empty dice rolling.
