Lazy thinking. Although deadlines should be avoided as much as possible and should be viewed realistically (shit happens), lots of things that depend upon the shipped product need to be planned well ahead of time, and can't easily be changed.

Such deadlines aren't there to annoy engineers, they are there because a lot of things need to be coordinated to happen at exactly the same time and place. Software is a means to an end, rarely a goal in itself.

Also, the "it ships when it ships" leads to an attitude in which nothing ships at all. Even if it's no hard deadline, people need a target in which they can frame their effort, especially if it's a joint effort. Nothing is more frustrating than really wanting to get something finished but your coworkers on who your work depends want to do something else. Without a fixed timeframe as a joint reference, it's very hard to stay in sync and make joint progress. I've seen it kill productivity more than unrealistic top-down deadlines.

Finally, there's no excuse for not making the effort to get better at estimating. I've seen well gelled teams play planning poker, give exactly the same estimates independently and hit their targets perfectly. It's not an exact science, but it's not dark magic or wild-ass guesswork either. It's a skill you can hone, especially as a team.