Steve Maine blogs about the case for software factories. He uses Timbuk2 as an example of what software factories could be like.
What Steve is talking about with Timbuk2 is known as "assemble-to-order" in Operations Management. It's the same thing that Dell does. The vast majority of the manufacturing work is already done, and is just put together as the final product. A bonus is there is much less inventory to hold, as you don't have to hold safety stock for each and every model, just safety stock for each subassembly. Some simple statistical analysis will show that the safety stock needed for this situation is roughly half (or less!) that needed for all the products if stocked in final form. Not to mention the benefits of a pull demand model versus a push one. The customer ordering a computer and Dell building to that order is a pull model, whereas HP sending out a bunch of computers to CompUSA and then trying to sell those computers to customers is a push model.
How does that relate to software factories? Well, if you can assemble your software from pre-manufactured subassemblies, then great! I highly recommend using pre-built and pre-tested code whenever possible! However, I think that software should solve new and interesting problems, which kind of negates the whole advantage of software factories. Now if you have an operation like Scott Hanselman does at Corillian, that's an excellent example of a software factory. But notice how narrow the market is for the apps they sell! Yes they customize the UI, but Scott has blogged on numerous occasions on how they generate a large majority of code at the beginning of a project (order really, the flow model again).
I think software factories may be applicable to narrow vertical market applications. But then, why not just make the application configurable instead of assembling it to order? Microsoft has proven that mass-market software works, and it is highly profitable.