I read over the full text of this article (what can I say, Fridays at the office are slow) and thought that it was quite an interesting read, even if I don't agree with several portions of it. It sparked an entire group of areas on which I wish to comment, though, so I ask you in advance to please forgive the topic-jumping into which this will probably descend. I'll try to keep the different sections distinct.
<p class="sectionbreak">Patterns of Use
I've got to admit, right off the bat, that I'm an entrenched computing elitist. I have no illusions about the fact that my habits are widespread or even optimal (I tend to compulsively shift-J (vi: join line, for all you who have not yet seen the light ;) text with hard linebreaks between paragraph tags when editing HTML, for example. This stems from my twin beliefs that ((a) the menial job of line-wrapping should be left up to the computer), and ((b) if I'm editing text in an editor that is 300 columns wide, I damned well want to see lines that contain as near to 300 characters as possible. If I did not, I would have resized my editor to begin with)), so I don't think that everyone should adopt my style (hell, if everyone did, the world would explode).
This being said, there is still some truth that I can see by comparing (or, as is more common, contrasting) my style of use with those of others. Everyone tends to have a specific group of actions performed sooner or later during the course of running a program. I normally tend to examine the command-line options (if they exist), read through the configuration files (whether or not they are binary - there are some gems hidden in there sometime. Has anyone every bothered to look through the executable file for Dark Forces (the first one)? Scroll to the very end (shift-G) if you get the chance), thoroughly read through the documentation, cycle through some common tasks once or twice and then customize the hell out of it. I tend to avoid pointing devices in general, and try to ensure that my hands spend as much time on the keyboard as possible (in fact, my adoption of this discipline normally makes people think I'm an expert user with any program I use, even though it may be the first time, simply because I can operate the program in such a frictionless fashion). I read all dialog boxes and pop-up messages (at least the first time), but I also tend to quickly build up a library of "recognizable" boxes that can then be safely acted upon without delay.
My pattern is almost the exact opposite of the one alluded to in the article, which sums up at one point that "Users don't read stuff; Users can't use the mouse (where he actually argues that users can't use the mouse well, not that they eschew the little desk rodent entirely); Users can't remember anything" (see the bottom of page 8 for reference). However, there is still insight to be drawn - people tend to fall into patterns of use that persist across sessions, programs and even entire environments (I tend to read the manuals of electronic devices and other toys that I buy; friends of mine who religiously ignore pop-ups and alert boxes often begin answering test questions before having fully read them). Via these patterns, they - we - develop the expectations of which Joel Spolsky writes: witness the anecdote of a Windows user trying to help a friend with her Macintosh (on the first page, search for "iBook") who is frustrated because it does not work the way he expects.
Now, unlike the author, I am not saying that what the majority of people expect is uniformly right. If my fellow geek friends used their computers like everyone else I know, I'd end up carrying around a baseball bat as an educational aid. By all means, make any program obey convention - make it behave like everything else on the market. But for the love of $DEITY, do not force me have to conform to the patterns of some other demographic! If I care enough about different defaults to change them, I will either already have the technical know-how to do so or I will quickly learn! Offer defaults, but don't enforce them. Frankly, if every program that presently features "skinnability" would instead allow the modification of the interface (hell, I'd settle for keyboard remapping, given that the studded oblong board is my physical interface of choice - but again, that's just me), I'd be ecstatic.
<p class="sectionbreak">The Myth of "Simple (limited; many new converts) versus Powerful (general; hardcore zealotry)"
There's this persistent belief that something can either be simple or powerful. People bring it up all the time during debates with huge topical ranges: *nix vs. Windows, Windows vs. Macintosh, manual transmission vs. automatic, DVD vs. VHS (I kid you not, I've overheard arguments about whether or not it's worthwhile buying the DVD version of a film because of the added overhead of navigating through the menu to get to the film, whereas with VHS "you just stick it in and it plays"), multiple-choice (machine-readable "Scantron") vs. short-answer tests in school, N64 controllers vs. PlayStation controllers... the list goes on and on (note that I've focussed mainly on (perceived) technical dichotomies; the meme itself, though, of [simple, limited, with a large flock of new users] vs. [powerful, general, with a small core of dedicated fanatics] is very widespread. Take a moment or two to consider it in relation to any long-standing debate that comes to mind - it may be applicable, sometimes in a surprising fashion).
This dichotomy does not necessarily exist, though - it /is/ possible to build a simple, easily-approachable system that also contains great depth, power and subtlety to those who take the time to immerse themselves. Consider language - although daunting in its entirety, a foreign language can be partitioned into small, easily-digestable chunks: conversational guides and the like rely on this approach. You don't need to be able to create literary works of the depth and power of Dantes Inferno in order to ask where the bathroom is during your next visit to Italy. You don't need to understand the internal workings of the microcontroller at the heart of your VCR in order to watch a movie (hell, the profusion of blinking "12:00"s is evidence enough that you don't need to grasp an entire system in order to use it in an effective fashion). For many systems, it is not necessary to master all the quirks and complexities thereof in order to be productive or to accomplish your goals.
How about an example: a "search" function implemented in, for example, a web browser. Right now, I can't think of a mainstream (I don't count Lynx as mainstream, although I am fond of it) browser that offers more than a simple case insensitive match-search. Now, sometimes I yearn for full Perl-style regular-expression matching - especially when browsing through huge, hundred-plus-kilobyte documents. If I had the time and energy, I might even hack something together and drop into Mozilla (who knows, it may already have been implemented - everything else seems to have been (disclaimer: I'm a huge Mozilla fan, and have been among the first to cry "foul" when people unduly lambast it... but it is getting a little feature-rich these days)). You'd be hard-pressed, though, to find anyone who would suggest that any user wanting to search through text should be forced to learn regex syntax (well, OK, I'm sure we all know at least one curmudgeon who'd wholeheartedly support that idea, but you get my point). It is not necessary to make a black-and-white decision to support one or the other, however - there is plenty of middle ground to cover. You could implement a filtering system like the one present in Eudora Pro ("item contains  ((and/or)(does/does not) contain  ...)), which is a more powerful and flexible version of a full-text search, or you could implement Rebol-style parsing rules (pages 429 through 456 are relevant), which act like demystified regexes (I love regexes - I mean love them, which is probably unhealthy somehow. but I'll be the first to admit that they're cryptic. A non-programmer (test-case: my father) read and understood a Rebol parsing rule on the second try). Neither of these suggestions is the perfect balance between power and simplicity, of course, but I would go so far as to say that the Rebol solution is as powerful as a traditional regex while being comprehensible enough for relative neophytes to employ as a viable solution.
I'd also like to attack another commonly-held illusion: that of the balance between widespread acceptance and critical acclaim. It would be a pretty silly claim to make that most users consider (vi|emacs) to be their primary editor, but for those who do, it's a very personal and vigorously-defended choice (hey, everyone has to have a crusade, no?) ("Why would I want to download $Word_Processor? I can do my writing in LaTeX-mode, after which I can upload it to the space on my shell account via angeftp, filter it into HTML and re-read it via W3. Do that in WordPerfect!" ... "Why would I want to download $Word_Processor? I can do all my troff authoring in a task-specific, space- and CPU-efficient editor, do all my editing with a minimum of keystrokes and render the output without having to quit my program to free up the RAM. Hey, shut up - real users use troff. And vi. Well, I guess Vim is OK."). In this case, they're not terribly widespread (in general - I know that the intersection of (((vi) OR (emacs))-users AND (kuro5hin.org-readers)) is probably pretty large, but in this case I'm referring to all computer users - that includes your Mac-loving grandmother) but they have a dedicated and knowledgeable core of users. On the other end of the spectrum, there's Adaptec EasyCD Creator, which is just about as ubiquitous, widespread and beginner-friendly as you can get (although more advanced features have accreted over the past dozen or so releases, they remain mostly hidden). I don't know many people who take their CD burning seriously that use it, though - more often, they've graduated to Nero or CDRWin which, although more complicated, are substantially more versatile.
This doesn't mean that there are only two real classes of programs ("aimed at those who know no better" and "intended for hardcore users"), though. Winamp is a great example of a program that's very beginner-friendly and yet still has a great deal of customizability available to those that go searching for it. Internet Explorer (shudder) and Netscape more or less fit into the same category, although both are getting a little top-heavy these days. None of these examples offer a very smooth graduation curve from beginner to advanced - there's a plateau beyond which most beginners won't venture, and everything above this division tends to be aimed at the archetypal technical user, not the beginner who is looking to learn more - but my point is that it's not necessary to pander to one audience or the other.
<p class="sectionbreak">To Sum Up
The point of all this blathering is that it's not necessary to aim solely for the lowest common denominator. This article seems to reccomend that any interface should present the "path of least surprise" to every user in order to increase productivity. I would tentatively agree with this, but only if this is done without placing an artificial cap on the ease with which an expert user can manipulate the program - if someone writes a program that, for example, makes it really easy to put together graphs, and is really easy to pick up because it's only got six well-defined, round-edged buttons that make everything work, but that will only graph, say, bar-charts with ten or fewer samples, then by golly I'll take the time to learn Gnuplot or Maple or Mathcad. It's important to make a program easy to use and learn, but only if this is done without restricting power and generality. You can only simplify a task up to a certain point, beyond which you start losing potential power. It's like perceptual audio coding - you can only throw away so much useless stuff before you start seriously cutting into signal quality, no matter how clever your algorithms and heuristics.
Moral of the story: "Make things as simple as possible, but no simpler". (A. Einstein)
My God, I wrote a novel. I should have wrapped that up pages ago. Someone stop me before I post again.