Functions like these let you store and retrieve complex data structures to and from simple scalars. Most time it makes sense to use standardized formats and data storage systems (properly defined file formats, databases, etc...), but if the data is for internal use only or to pass data between two of your own scripts, it sometimes makes sense to use storable.

Say, for example, you have two scripts running in parallel. One of does some background calculations and the other one wants to display the preliminary results on a web page. The results are a complex data structure. One of the cheap-and-dirty ways to accomplish this for the background process to just freeze the structure into a scalar and write it to a file (or use Cache::Memcache and a database text field, etc) every once in a while. When the webpage is refreshed, the Perl script loads the scalar, thaws it and dumps it into a Template Toolkit template that renders the required data.

This way, the webpage developer doesn't even have to know which datafields there are or what they mean. And the guy who wrote the background process doesn't have to know much about web programming. Only a few basics on how to use TT...

Also, if the background process puts all it's internal states into that data structure, you can use this to quickly implement a "restart from last savepoint" feature with a few lines of code. Without ever having to write a complex savefile-generator and an equally complex parser.

As mentioned, the limitation of approaches likes this are plenty. Talking with programs in other languages or even Perl programs written by other developers can get ugly very fast, since the data structures most likely reflect the internal state of whatever your program is doing with the data - so every internal change gets passed on to your communication partner. And even loading older savefiles from your own software might be problematic...

Hope i got everything right and made the topic a bit clearer...