Banded reports have been the standard for a long time. In the article Banded Reports are Evil, the point is made that oftimes they are used when an alternative approach would be both easier to use and allow the developer to create the report they actually want.
There are a large number of articles about how Pie Charts are Evil. Now evil is overstating it and there are times pie charts are appropriate. But the vast majority of the time when pie charts are used – they shouldn't be. (I think this is mostly due to people assuming pie charts are the standard way to display percentages.)
The same holds true for banded reports. There are cases where their use is appropriate, but that is a very limited sub-set of where they are used.
So what are banded reports? This is the approach used by Crystal Reports, SSRS, Pentaho, Jasper Reports, Actuate, etc. A report by definition is composed of a report header, a table, and a footer. The table component can have multiple levels of detail, with aggregation at those levels (this is where the term banded comes in).
When this fits the report you want, a banded report is a great solution. If the data comes from a single stored procedure, all you want to display is the data in the single table, and the detail levels and aggregation desired are easily set in the report designer – a banded report designer works well.
But when your needs are different, or more, then this locked in approach becomes a significant problem. Fundamentally banded reports are about limitations. Limitations that can be broached only with great effort and significant compromises.
The blog post is continued at Banded Reports are Evil