One, you can have configurability allowed even after providing the "sane" default and, in fact, advanced users demand this.

They can demand all they like, but adding configurability to an application means adding interface, adding complexity and adding new behavior interactions. As the third impacts mostly on the application's developers (who must determine and test the possible interactions for QA purposes) I'll pass it over, but the first two certainly impact usability one way or another for various groups of users. The second one in particular is important to look at in detail, because while some users won't have trouble with a more complex interface, many users probably will. And if the interface change is being implemented solely at the behest of a small group of users, then it appears to generally be a net loss for usability. Which means it shouldn't be implemented; while not by any means an ironclad rule, that sort of utilitarian calculus makes for a handy rough guideline in usability decision-making.

Furthermore, you seem to have assumed the truth of this implication: if a given user is an advanced user, then that user will desire additional configuration options. Universally quantified as it is, however, that implication is trivially easy to disprove.

And whether you care to admit it or not, at some point you are going to have to deal with advanced users. Simple math, there are a finite set of newbies..and over time those newbies will become advanced users.

Not every new user becomes an advanced user with time; most users, even those who receive thorough training and documentation for an application, only ever learn as much of the application as they need to for their daily interactions with it.

Its a fairly fine point but you must read through it. It is FOLLY for a design team to think that they can design for all contingencies and for all users. Because of this, the best applications are highly configurable.

A simple logical extension of that argument would conclude that it is folly for a design team to think that they can anticipate all aspects of an application which users might wish to configure, and thus that even highly configurable applications would fall short of being defined as "the best" (where "the best" is a dangerously vague term -- the best at what exactly?). At any rate, the impossibility of pleasing all of the people all of the time was solidly confirmed long before the advent of programmable computers. But as I have never once stated that a design team should attempt to design for all contingencies and/or all users, or to think that it can, I suspect you're replying to an opponent made from the dried stalks of cereal plants.

And the number of personal experiences in the latter case equals the number of computer users...which means that regardless of the amount of user testing you do, you will never have tested a "significant sample size" to determine if you have it right.

There are two erroneous assumptions apparent in your statement here:

\r\n
1. You continue to rely on an assumption that all users must be pleased all of the time. I've already pointed out that this is an impossibility no matter the number of configuration options offered, so we must return to the utilitarian calculus: what is the largest portion of users that can be satisfied for the largest portion of time? Answering this question generally leads to the exclusion of (what you assert to be) the demands of so-called "advanced users", as the complexity such users are willing to accept from interfaces is generally beyond that which so-called "average users" will accept.
\r\n
2. You assume that user testing is the only means by which developers can determine whether they "have it right". In actual fact, developers have access to information from a variety of other channels besides user testing, and good usability processes take advantage of as many of these channels as possible.
\r\n

There are folks here that have continued to use Warp far beyond its useful life and I'm convinced that it is because of this last point. They, by now, have Warp doing things that probably can't be configured into other interfaces..and if your theory holds, should not be allowed.

Again, two problems leap off the screen:

\r\n
1. If configurability to the "utmost detail" truly does result in significant usability gains, then Warp would not be a museum piece.
\r\n
2. You seem to conflate, as Peter pointed out, "flexibility" with "configurability". Flexible interfaces need not necessarily be configurable, and configurable interfaces are not necessarily flexible.
\r\n

that any one factor ever is the sole cause of an interface's success or failure; the real world is never that simple.

But if the level of configurability in OS/2 Warp truly had a significant impact on usability, then one would expect something more to have come out of it, even if only in a legacy of ideas living on in other systems. As it is, the ideas which are being extolled here are not the ideas from OS/2 Warp which actually did live on.