Object oriented programming - and memory matters: Abap has come a long way and Object Oriented programming hopped on the train somewhere. The Object Oriented paradigm has a clear answer to memory management matters. Memory garbage collection is something the Abap developer does not have to look after - the system does it for us.
A report can hold a local class for which the memory management is part of the report. The data on a class (attributes) as well as methods (and types) all have a "visibility", which is very much the memory management thing. Visibility: definition of where attributes (methods, types) can be "seen" (accessed) from. Visibility public means available to whoever uses the data. Visibility protected and private limit this access to subclasses or only the class itself. It is also possible to make the data on a class available in the public section, but as a read-only attribute. And to make matters complete, the local class which only lives embedded in the report supports all these features, but so does the global calss (object builder, SE24) which is available to any bit of Abap coding.
So using classes allows the developer to organize data to a great extend, making the arrtibutes that could matter to anyone available to anyone, and sheltering temporary data where appropriate. There is no need for Abap reports with hundreds of data declarations, all stacked together. But wait, there is much more to Object Oriented programming than visibility. Check it out !