Eight years later, we finally know the answer to Joel's question.
It's easy to point and laugh at Sun, but that's the same approach to open source (and standards) that Apple used to get out of the shadow of Microsoft and they seem to be doing okay.
(The same probably applies to Sun breaking lock-in to Intel based hardware architectures. Again this applies to Apple as they had to switch from PPC to Intel, but their cross-architecture experience gave them the leg up on ARM based phone and tablet markets.)
We may still get to watch Oracle making hay on that.
 for example here: http://blogs.zdnet.com/Murphy/?p=1701 (There may be better pieces out there, my interest in this is limited.)
Having said that, recent history indicates that Joel's take on Sun's problems with their strategies (plural because they flip-flopped strategies) ultimately was correct.
I seem to recall Mother Teresa being told by a reporter that they couldn't be paid enough money to do what she did. Mother Teresa's response was something along the lines of "You couldn't pay me enough money to do it either". For me the loss of time and money is negligible compared to what I gain in learning, which is immeasurable.
So when he's arguing against the "claim that it's OK for every Linux kernel revision to make all existing drivers obsolete, because the cost of rewriting all those existing drivers is zero", he's saying "there is a cost, it's just not monetary." The alternative to requiring people to rewrite device drivers is having some people make the kernel backwards-compatible with old drivers. Presumably that's simpler than rewriting every driver. What else could you add to Linux if that many developers could do something that wasn't rewrite working code?
Joel is talking at the level of corporations, not of individuals. All of his examples are of the strategic move of a company, not the personal belief of an individual (or the collective action of a group that is united by their beliefs). And the major take-away is, you don't need a non-monetary incentive to support FOSS, because there are monetary incentives. Open-source and profit-motive are not inherently opposed.
So yes, the assumption he's making is that money is an incentive for promoting open source. For some, especially for companies, it is. For some, it is not. It's reasonable to expect that when companies are supporting it, they have something to gain by doing so, and Joel is spelling out how. That doesn't invalidate the personal motivations that some people may have, but neither do those motivations invalidate the more traditional monetary motivations that the companies (and some individuals) have either.
Having said that, I don't think he's wrong on the big picture economics, more on the particular facts of the examples. It's about people wanting to ship binary drivers rather than just release the source so that others can fix it for you. Or generalize it so that your specific hardware widget is just one of many similar widgets all running the same basic code that can be mainained at a much lower cost (by any measure).
Of course hardware folks don't want to do that if they feel they have lock-in, for exactly the reasons discussed in this article. They don't want to be an interchangeable commodity, Linux and end-users do want them to be commodities. Once again Free Software is shown to be about who has control, not how much you pay. (Though probably mostly it was just fear of the unknown)
More recent developements include the Linux Driver Project:
"We are a group of Linux kernel developers (over 200 strong) and project managers (over 10) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 Linux kernel driver as an end result."
Not at all. Economics is about "how to best allocate scarce resources". "Resources" for an open source project translate to manpower or developer hours.
Given that you develop primarily for fun and learning: Would you rather spend this week making the 17th version of the same hardware driver (because the latest Linux core version broke it), or would you rather spend that time on attacking a new problem?
The economic argument is simply that if
a) making Linux backwards compatible takes x developer hours
b) updating every Linux driver in existence takes 1000x developer hours (summed over all developers)
then choosing b) is a net loss for Linux, since all those extra developer hours could be spent on something more interesting.