In some projects, you have to follow a strict development process, which may not be iterative. An example for these is in the aerospace sector when you have to deliver software by DO-178B/C standards and the like.
For one, you do not even have a choice in those cases. You couldn't develop iteratively even if you wanted to. But more importantly, these projects do not lend themselves to iterative development very well either.
Think of writing control software that gets shot into space (literally!). There is no more room for improvement once it's on flight (it's already different if your thing would start to operate on the moon or the ISS, because software patches become possible). Additionally, the hardware being controlled is typically very mature and requirements have been well analyzed and are very seldom subjected to changes.
Similar cases happen in software that needs to be certified. While you can develop those iteratively, there is a certain point at which you have to declare the whole thing complete in order to get the certification. After that, you must not touch the software again, or your certification is void. Again, a scenario that doesn't exactly favor iterative development.
That being said however, I notice more and more software projects in these sectors going for incremental developments (within the unchangeable frame of the required specification standards). Also, great care is taken to reduce the amount of software that cannot be developed iteratively (or just needs certification) and clearly separate it from the remaining software. The monetary advantages of this move are obvious (at least to anyone who has ever seen the cost of software that controls a plane), but it's also the typical text-book advantages of incremental development that the product developers are interested in.