While it is indeed unreasonable to expect that products will ship exactly on announced dates, and that pressuring people to do so might result in the release of still-buggy code, I think there's room for more discipline than is in fact being exhibited by the Linux kernel gurus. Scheduling software projects is not totally a black art. People experienced in a particular kind of programming can often come up with remarkably good estimates of how long things will take, how much extra time to allow for bugs that fall out during testing, etc. Nobody's perfect, but it is entirely possible to come up with a date whose percentage probability of being met is in the high nineties.
Why doesn't this happen in Linux? Two reasons: optimism and lack of discipline. There's no significant penalty for missing a date in open source, so there's no incentive to be pessimistic. When people aren't afraid of the consequences for a date being wrong, they'll usually give you a "best guess" - 51% confidence - date. People who hold themselves to a higher standard of diligence might give you a 90% number, but the project as a whole invariably ends up delayed by the people who couldn't be bothered coming up with a solid number when the project started.
Lack of discipline bites us in several ways:
All of this adds up to create an extremely unpredictable development environment. It's only because of hard work and raw talent that Linux kernel release dates aren't ten times more of a joke than Microsoft's have ever been. With talent and work and just a tiny bit of engineering discipline, we could do a hell of a lot better than we're doing wrt release dates.