Since the shape is always different, there's virtually zero useful information to take away from it.
Some people in this thread claimed that burn down charts are useful for finding out a team's capacity. I disagree - you don't need a chart for this. If your team has a target velocity of 30 points and routinely fails to meet it, reduce the target velocity. Likewise, if the team routinely completes all of their work well before the end of the sprint, slightly increase the target velocity.
My insistence is always that what happens inside the Sprint is the concern of the development team and nobody elses.
However it's important to remember that the team itself should set their velocity in negotiation with the product owner. This shouldn't be set by some external force.
I guess the idea is that points should correlate to time (questionable), and if you're estimating perfectly, that should give you a linear burndown graph. Which is stupid. What might be less stupid is that if you want to get some idea of how well your team is estimating tasks, compared to i.e. this time last year, you could look at the volatility (across several sprints) this year compared to last year, and a lower burndown rate volatility might suggest that the team has improved at estimating the duration of tasks.
However, when you just focus on the volatility as a metric, then people start optimizing for it, which is not the point at all.
Unfortunately, what most organizations actually do is use the progress estimates to try to bludgeon developers into working faster, with entirely predictable bad effects.