Not to throw down, but do we even have a definition for "perfect" software? Because I could quite easily argue that not only does the definition not exist, but it is impossible to create a consistent definition for all potential users. The field of MP3 players is a good example: The iPod dominates the market for some strange reason, but many people view other MP3 players as "worse." More buttons would break the "perfect simplicity" of the system, but the inability to arbitrarily build and shuffle playlists is quite obnoxious.
Internet browsers are another interesting domain. My company uses a web-based MIS designed with Internet Explorer 6 in mind. One could blame the system for poor design for reliance on proprietary ActiveX controls, but we're stuck with it. That said, IE6 is the "best" browser can offer to our employees, because Firefox, Opera and Chrome will not function. We're not even touching "perfect" yet.
But I haven't really address the question of the cost of developing "perfect" software, so let's make some assumptions. Let's view "perfect" from a security standpoint (accessibility, confidentiality and integrity) and use Common Criteria as the metric of software goodness.
The first EAL of CC are pretty easy to come by, since the basic definition is that the software works are doesn't crash. The next levels require discretionary (optional) protection, followed by mandatory object protection. That's nothing too interesting, as software of any importance should be doing this stuff anyway. Top-tier perfect software development involves formal verification of the software - as in, developing a description and proving that it will always work. More work is involved proving that your software actually matches the mathematical description of your software, which costs money. If you've ever tried to formally verify software, you will quickly realize that it takes AT LEAST the same amount of time to verify the software as it did to initially develop the software. There are shortcuts such as Automated Theorem Proving, but it's an NP-complete problem and you're going to need to pay (at least) a person who understands it.
So what if we don't want to formally verify our software, but at least check it until it's "good enough." You could hire some hackers to independently test your software, but that costs money. You could internally check it, but that takes time (read: money).
What we really need is a testing facility that integrates well into and speeds up development, which is pretty much what unit testing is for. I can say a lot of good things about unit testing, but they're certainly far from perfect. They take time to develop, but if they help catch glitches, then you're actually speeding along development. Honestly, I couldn't tell you if the net result is time savings, but I can tell you that you can only catch the errors that you are looking for.
In conclusion: I disagree with your statement that developing "zero defect" software costs the same as developing and shipping software with defects. Formal verification is nice, but completely unreasonable to ask for. Independent testing will always cost more money and internal unit testing lacks the independent thought that really finds errors. I would love for software to be perfect, but it is simply too much to ask for out of developers today.