This^^^. Scheduling for some types of software is harder than others. I mean it's always a pain in the neck, but not necessarily intractable.
I used to work on shrinkwrapped tools for SQL Server and .NET developers, and over time got pretty good at scheduling releases with an ever narrowing window (that was never that wide to begin with), even accounting for the inevitable changes you'd need to make as you got customers to try out the software throughout the project. And you needed some degree of certainty over scheduling in order to coordinate with marketing, make sure sales and product support were trained, dovetail with other projects so that people could be reassigned, etc. Key point, as well: teams are cross-functional, but relatively small.
Line of business apps are trickier because you're often dealing with stakeholders who either aren't sure, or can't well express, what they need. You also have the kind of integration problems that occur much less often than with shrinkwrapped software. Cynically, I feel like a lot of unwillingness to schedule for these kinds of projects - especially for moderate team size/complexity - is really because people just don't like doing it, for a variety of reasons. And by schedule, I mean sit down and do the homework as it were in detail, not just throw a convenient date up on the board (I've never seen anyone do a good job of estimating a software project in the large this way, and it doesn't help the business make informed decisions when you end up shifting the date or cutting functionality under duress later on).
You get similar problems with public facing web apps: because you can roll out a new version of the software whenever you want this allows you to chop and change functionality as needed (or wanted), so things can grow tentacles. Team size and complexity can vary a lot here but, obviously, bigger, more complex teams make it harder to schedule. If you're rolling out functionality incrementally though, this may not present a big issue commercially.
Games are a whole other thing, because the feel of playing, and the fun factor are absolutely key. This is also why I don't think film development is a great analogue for game development. Film is not interactive, but games are, which adds a layer of complexity film doesn't need to worry about. And this comes whilst having a production team of a comparable size and complexity to that of a film for big budget games.
To be honest though, I'm not sure how much team size and complexity factors in with games - just watch the Indiegame film where you have very small teams in all cases, yet (particularly memorable with Fez) development takes massively longer than expected, and involves a rewrite to get the game right. If that hadn't happened it wouldn't have been as good a game.
Like I say, I think games really are a different kind of problem - perhaps the closest thing software project management has to an NP-hard problem. It's really no surprise they ship late, and that crunch is a reality. Perma-crunch though: well, that just makes me feel sick to think about.