Reason #1: Their motivation
Tracking Gantts let you see, for each step of your plan, how long you thought it's going to take and how long it's actually taking. You get to know, every day and in status meeting, that phase X was supposed to start by March, but it's clearly not going to get started until May.
You already knew, when you did initial planning, that the plan is going to have to change as the project progresses. New information comes to light. People and resources are unpredictable, etc. So why is it important to constantly be reminded, in every status meeting, how poorly your early predictions are fairing in real life?
Reason #2: They force you to stick to the original plan
The very idea of tracking a project's Gantt chart means that instead of focusing on constantly adapting your work plan based on new information, you choose to stick to an outdated plan, just because it lets you point fingers and highlight the mis-predictions that were the inevitable result of the huge amount of uncertainty that the early planning phase of the project entailed. After all, you can't track the Gantt if you allow the plan to change radically, right? It has to have the same general shape and be comprised of the same steps, otherwise there's nothing to track...
Boneheaded sticking to plans is the number-one reason why "Waterfall" is actually considered a pejorative term these days. Planning ahead is confused with sticking to the original plan.
Reason #3: They teach you nothing
It's not like the delay in this project is actually going to change the way you plan the next project, unless the projects you're planning are predictably similar and repetitive. After all, that's what Gantts were initially used for - planning work in factory production lines, where tasks are very well defined and their duration is extremely predictable.
The value that tracking adds to a software development Gantt chart is zero. Arguably even less than zero. Not only are past estimations irrelevant for new projects, the illusion that you can actually improve your estimation ability over time by retrospection is dangerous. Sure, a CS student might really not know that integration takes lots of time in real life. But anyone that's been involved in more than two projects in their lifetime is already well aware of the usual suspects for delayed projects. The real reason projects are delayed is not some mathematical error factor that must be applied to estimations in general - it is the inherent uncertainty that comes with doing something for the first time and not knowing exactly how it's going to pan out.
There are actually project management systems out there that try to attack the problem from this misguided angle. They measure your predictions vs. actual performance and try to correct your overall estimation using statistical analysis. As if "Danny always underestimates everything by 14.3%" is ever the case. Danny isn't stupid, and to assume that the error of his predictions is predictable is indeed idiotic. It confuses the primitive "cure" - adding factors to your estimation - with the cause of the problem. Your estimation isn't inaccurate because it wasn't multiplied by the "correct" factor. Your plan is simply incomplete; and every plan is incomplete in its own way.
Reason #4: They focus your attention on the wrong things
Instead of being focused on what needs to get done to deliver on time, you're now focused on justifying your inaccurate predictions. Instead of focusing on planning in more detail and adapting your plan to new information, you're rehashing an outdated plan. Projects are seldom delayed because the work-plan's parts were incorrectly estimated. They're delayed because a crap-load of things were simply left out of the original plan. Tracking Gantts make this even worse, because what sort of motivation do you have to insert more detail into your plan if it's all just going to wind up highlighted as a poor estimations in every status meeting? They make you stick to large, track-able chunks of work in your Gantt chart. Instead of letting you focus on adaptation and getting on the right track, they make you reexamine irrelevant decisions that were made when less information was available.
There's also the problem of not having good enough tools to manage sufficiently elaborate plans. You have a much better chance at constructing a good initial plan (and estimation) if your tools allow you to expose all those frequently neglected steps along the way. Traditional Gantts are low-resolution beasts that are rightfully seen by developers as caricatures of the reality of project management. What's needed is a tool that makes it easy to add as much information as possible to the work plan at the earliest stage, and then make it just as easy to adapt your plan as the fog of uncertainty slowly fades away from over your project. The last thing you need is incessant low-resolution reminders of your inaccurate past predictions. Tracking Gantts are good for pointing fingers and covering asses, not for getting things done.