In our organization, there are several reasons. A few are pretty specific to our case, and others a bit more generic.
1) Incompatibilities. We have had a few cases where software that was written in-house for SQL2005 has issues when installing on SQL2000. The case I saw most recently ended up being due to parameters being explicitly declared that don't exist in 2000, and a difference in the name of the system index table. (sys.indexes vs sysindexes)
2) Training. Our developers certainly know 2005, and would prefer to be developing on it, or 2008 already. However, the job of keeping everything operational falls to the NOC, not the developers. Nobody in our NOC has had any formal SQL training, and the differences between the two, just from an administrative tool standpoint, are enough to make this a consideration.
3) Cost of upgrading existing products. For us, this is a big one. I'm not talking the cost of the license from Microsoft here. In our business, an upgrade on any of our existing products (even if we didn't retroactively upgrade everything already in the field) would require an expensive and lengthy re-certification process through several different regulatory and certifying test labs. We are building new products on SQL2005, but not upgrading older ones for this reason.
The certification process also means we would end up with a mixture on new builds, where certain jurisdictions would be getting SQL2000 and other would be getting SQL2005, based on if the approvals had been received yet or not. We prefer, for reason #2, to keep our production environment as consistent as possible.
4) General differences. This is really an extension of #1. There are lots of little things that changed, some of which cause us headaches. Example, SQL2005 on Server2003 will enforce Windows password policies on sql accounts. Not a bad thing by itself, but it breaks almost all of our (and much third-party) software because of the way we interact with the database.
In short, inertia.