The 180-day default fsck time is a workaround for the design flaw that ext3 does not support an online consistency check. The real solution is to find a filesystem that supports this. I don't know if any mature filesystem does. It's a real tragedy. Perhaps btrfs will save us one day.
I've responded to the issue of the surprise multi-hour downtime from fsck by doing scheduled reboots with a full fsck as part of standard maintenance. This is better than running into minor corruption during production hours, and having it turn into a real outage.
A big part of the problem is that ext3 has an unreasonably slow fsck. Although xfs has a much faster fsck, it uses too much memory for distributions to encourage xfs by default on large filesystems. Still, on most systems this is a non-issue. Switching to xfs would at least allow for a reasonably fast fsck. This may make running fsck as part of normal maintenance easier to schedule.
If you're running RedHat and considering using xfs, you have to beware of how strongly they discourage the use of xfs and the fact that there are probably few people using xfs on the kernel you're running.
My understanding is that the ext4 project has a goal of at least somewhat improving the fsck performance.