I think he's actually somewhat correct about multi-threaded programming, at least in some areas. Multi-threading works (aside from all the problems Yegge mentions) when you're dealing with multiple cores in a single box, but it doesn't scale at all well across a distributed system. As a counter-example, Map-Reduce has exploded since Yegge's post, as a way to get practical parallel speedups for certain kinds of tasks, without even having to think about race conditions, deadlocks, etc. Now Map-Reduce isn't useful for all the same problems as multi-threading, so one isn't going to replace the other, but it's just an example of an area where the multi-threading paradigm fails.
Distributed, message/actor models have exploded. There are better options to multithreading now. Only niches (often front end ui something) need multithreading.
Depending on what you meen by multithreading. Is multithreading when you use threads (and locks) directly or if your using multible threads in your programm in some way.
Acctully using threads probebly went back because of Actor Framworks, better understanding off developers, STM ....
Multithreading is certainly popular to pee on these days. It requires a fairly high level of understanding of how your data flows to get right, and languages do not help you out in that mechanism.
So CSP-based models have gained a lot of popularity, as a way to kludge around it and get most of the benefit (but shared memory is still a property of threading I don't see emergent in the CSP approaches currently).
To the extent that multithreading is popular to pee on, it's precisely because of the shared memory, or more accurately, the shared mutable variables. There's a lot of interesting concurrency solutions being developed, but it looks to me that shared mutable variables aren't going to be in any of them, so don't hold your breath waiting for them to come back. (The video at [1] is interesting overview of all the various Haskell solutions, which is interesting beyond just Haskell as an overview of a variety of concurrency approaches.)
Shared memory can give strong performance advantages that the alternatives don't have. You pay for this in implementation complexity. Each can decide how much he or she wants to pay.
The price could be lowered by some trivially better support functions. Why for example C++0x doesn't have lockless concurrent containers in the standard library is beyond me.
