Why companies release software with bugs

Came accross this article at Gurardian.co.uk, written by Eric Sink, founder of SourceGear.
For every bug fixed, there are new bugs being introduced into the software.  Every change is a risky change.  The bug that is being introduced might be worse than the bug being fixed or it might be not as bad as the previous bug.  So how do one know which bug needs to be fixed and when?
Eric suggest to consider the following factor:

• How bad is its impact? (Severity)

• How often does it happen? (Frequency)

• How much effort is required to fix it? (Cost)

• What is the risk of fixing it? (Risk)

An example cited from the article is when many potential customers asked to support Oracle besides SQL Server.

• Severity: Losing potential customers
• Frequency: None
• Cost: Very high since the original code was tailor-made for SQL Server
• Risk: Changing big portions of the code will surely introduce a lot of bugs.

So, sometimes, software just had to be delivered with some known but acceptable bugs.
Note: Although the example given is not about a bug but rather a feature of the system, but we get the point.
Reference: Guardian, Original article: Code Economist