Work only as many hours as you can be productive and only as many hours as you can sustain. Burning yourself out unproductively today and spoiling the next two days' work isn't good for you or the team.
Where does the penchant for long hours come from? I'm often asked for "scientific" evidence for the practices in XP, as if science could somehow bear the responsibility for project success or failure. Work hours are one area where I wish I could turn this argument around. Where is the scientific evidence that members of a software team produce more value in eighty hour weeks than in forty hour weeks? Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.
In my own case I think I turn to long work hours as a way of grabbing control in a situation in which I am otherwise out of control. I can't control how the whole project is going; I can't control whether the product sells; but I can always stay later. With enough caffeine and sugar, I can keep typing long past the point where I have started removing value from the project. It's easy to remove value from a software project; but when you're tired, it's hard to recognize that you're removing value.
When you're sick, respect yourself and the rest of your team by resting and getting well. Taking care of yourself is the quickest way back to energized work. You also protect the team from losing more productivity because of illness. Coming in sick doesn't show commitment to work, because when you do you aren't helping the team.
You can make incremental improvements in work hours. Stay at work the same amount of time but manage that time better. Declare a two-hour stretch each day as Code Time. Turn off the phones and email notification, and just program for two hours. That may be enough improvement for now and may set the stage for fewer hours at work later.