that's not wisdom; that's a sarcastic quip by the vim side of the emacs-vim/vim-emacs religious war.
http://en.wikipedia.org/wiki/Emacs#Emacs_pinky
As a novice Vim user who has at times wanted to try out Emacs, this has always been an irritation. I think it's telling that one of the suggested work-arounds according that article is:
> Emacs' built-in "Viper-mode" that allows use of the vi key layout for basic text editing and the Emacs scheme for more advanced features.
Emacs, especially with paredit, is fairly well optimised for editing s-expressions and the like. Vim is very well optimised for line-based editing, but I don't get on with its buffer management at all.
> underline an arbitrary line of text with '=' characters. In vim that's 11 keypresses across 3 operations
YpVr=
For those that are interested, I would recommend "Practical Vim", and it includes many examples (including the above one) which really accelerate the learning process:
http://pragprog.com/book/dnvim/practical-vim
There are definitely cheaper alternatives (including free ones), but this book really laid the concepts out very clearly for me.
I use Emacs to edit text, and I have limbs I'd rather lose than have to perform that task with Vim's airbag in my face.
Vim and Emacs both use key combinations... Vim's just require fewer fingers at once. You type Vim key combinations as you would type words in a language with a latin alphabet.
The key however is understanding that if you are insertion mode, then key sequences start with the escape key, or, insertion commands are completed with the escape key. There is no "context switching". No more-so then having to press ctrl along with the rest of your key sequence in Emacs is "context switching".
So the next question is: does the philosophy the author speaks of matches with the one of GPL, or rather, the one FSF and Stallman have in mind? Actually, I think these philosophies are different. If I remember correctly, in Emacs mailing list sometime ago, Stallman rejected idea of adding function to gcc to dump parse tree (or something similar) to use gcc from other software (I can't find the link right now). This was because non-free software could use gcc via CLI and "steal" the data from free software. Now, although it is the other way around, Emacs can use non-free external program. It matches with the philosophy by Matsuyama but I doubt that Stallman says it is the philosophy of Emacs.
I would say this philosophy is for author of Emacs Lisp program (though this was not what Matsuyama was talking about). You have many options. You could choose "maximum extensibility" but actually it is not doable due to GPL. You can follow FSF's philosophy (I am not sure what is it, but I believe there is). Somewhere in between, there is philosophy proposed by Matsuyama and it reflects current situation of Emacs very well, and I like it.
If that's the conventional wisdom, it is not particularly wise.
Emacs is much more like a Unix shell than any operating system I have ever heard of. Specifically, both Emacs and the shell fork and exec other programs a lot; a significant fraction of those programs communicate with Emacs or the shell via a PTY or a Unix pipe. In contrast, Eclipse does very little of those two things, according to the OP.
I think the philosophy of Emacs, if it has one, is "maximum extensibility". Whether that be with elisp or external processes matters not.
EDIT: forgot the word "conventional" :)