I recommend trying Gnus. The several weeks you waste trying to figure out how to point Gnus at your mail server more than pays for itself by the amount you learn while driving yourself mad.
I have a hard time agreeing with this statement, especially since I experienced just that. The only thing I learned was that the documentation for the process was awful.
Furthermore, the statement is some curious attempt at irony that undermines his argument. I don't want to spend 10 years setting up a development environment, I want to spend 10 years learning a development environment. Such a line can be very fine, indeed.
Building a mail system into a single-threaded text editor seems a bit silly to me...
Why's that? The (not gnus) mail system I use on Emacs will hang the Emacs process for a few seconds sometimes when I hit send while the Emacs process talks to my ISP's mail server, but that is the only way the mail system's single-threadedness ever really bites.
When I check for new mail on my ancient Pentium III system, the Emacs process hangs for less than a second or 2 usually.
Those delays are nothing compared to the time I waste waiting for Firefox to do something.
I prefer the Unix (and Erlang!) model of having lots of independent processes communicating, and individually serving a specific function. While I really like using Emacs's buffer-based environment as the common interface (such as working in a shell buffer and being able to edit results), I'm not convinced that adding more and more functionality to the same process is a good idea from an architectural standpoint. (And unlike Firefox, GNU Emacs doesn't even have good namespacing / isolation for its extensions, hence all of the variables with package-variable-name-with-several-parts names.)
Plan9's ACME preserves most of what I like about Emacs, but it's mouse-chord-based UI is a dealbreaker for me.