My experience with software development is that it's a combination of things:
Not enough resources allocated to a job, combined with poor planning.
There's that joke that goes around that devs always add 50% to the time they're actually going to take doing something in a quote, and then their PMs add another 50% on top of that. This isn't totally false and it's not always a bad idea either. A job you think will take you 4 hours may in fact take you a couple days to hammer out once you fix unforseen bugs, deal with complications that new requirements bring in (and I love Agile but that is one thing that happens with it), unit testing, QA testing, code review, and so on.
The only way to fix that is to plan out enough ahead of time, and nobody wants to look like the slow dev in the group.
Setting yourself up for failure
As a contractor, one of the things that I like about going into new jobs is the change of pace and often the huge, gaping problems that I was brought in to fix. It's perfectly natural to work extra to fix those glaring issues, and on top of that I have to say that it's a lot of fun at first to deal with entirely new issues. That, I think, causes a lot of folks to work a lot of OT, paid or otherwise, at the beginning of a gig.
Where that idea breaks down is that sometimes, especially if you aren't very clear about the fact that you're working extra time to meet deadlines, etc., the non-programmers on your team - BAs and stakeholders especially - get a false idea of how much you can produce in a week. That makes it extra hard to scale back 3 months down the line, as you then have to discuss why it is your productivity has gone down.
The constant death march
One thing that I have seen a pretty good amount of as well is a team being in constant crisis mode. It's OK to work a couple 50 or 60 hour weeks to meet a particular deadline, or if there's a major bug you've got to quash right now, but I've been at places where management seems to arrange things so that there's always a looming crisis right around the corner for... reasons. Some people think that this makes people more productive (I disagree but that's the thought anyway), sometimes you're coming in at a minus because the previous team spent a year to do something that ought to have taken them six months, and so on.
It's hard to come up with a good solution for this issue as it tends not to come from developers but from management. All I can say to this is, make sure you stay in constant communication with said management so that they at least understand the amount of stress they're putting on you and your team.
As noted, I do enjoy Agile, and one of the things I enjoy the most about it is the constant weekly or biweekly communication you get to have with people who are going to be using your product. You show off what you've added, they talk to you about how it differs from what they wanted, you make those changes and show them off at the next sprint, etc. I think it neatly avoids the really huge problem of Waterfall, which is that you can spend months working on something only to wind up with an end product that is all wrong.
That being said, Agile lends itself really well to people coming up with new ideas in those planning / demonstration meetings, and it's once again hard to be That Guy who says "that's not in the documentation. We can add it but it will add X weeks to the project". But someone has to be That Guy if you want to avoid scope creep possibly leading to the Constant Death March.
It's just the way we work
I think this is really the least important one of the bunch, but a lot of the time if I'm presented with a problem, I'm going to just sit down and work on it until it's solved. If that requires a couple of 14 hour days, then it requires a couple of 14 hour days. And if I can't take off early some time during the rest of the week, maybe I wind up with 50 hours plus.
This isn't a normal office job where you clock in at 9am, take a 1 hour lunch, and clock out at 6. I've noticed that non-programmers tend to be a bit less cognizant of this when they see a dev taking off at 2 in the afternoon on a Wednesday (they aren't seeing, of course, that you were in at 5 that morning because there was an issue you just couldn't put to bed until you solved it), but the overall point remains: this is a job where at the end of the day you are not judged by the hours you work but by the stuff you deliver.
You aren't always going to have to work 70 hours a week at a start-up, but bear in mind that for a small company that's just getting started, you're not just working for a paycheck, you're working to keep your company in business. Sorry, but sometimes you just can't avoid this. If you want to keep yourself around the 40 hour mark, find a Fortune 500 company to work for.