The problem of packaging components arises with the birth of the concept of a software component. If you have a piece of code that, by design, can be plugged into an existing application, or into a program that is currently under construction, then you need to figure out how to deploy it in a safe and seamless way. An obvious and somewhat natural metaphor that comes to mind is—yet again—with hardware components. If you buy, say, a sound card what you get is a package with the hardware board, maybe a floppy or a CD and possibly a reference guide. All this is wrapped in a single envelope you can order, or pick up straight off the shelf.
For Scriptlets—and more generally for software components—it is the same. When you buy a graphic library or an ActiveX control, what you get again is a package with some form of storage support, say a CD, and a reference guide. Typically the software is made up of a variety of files that need special treatment (things like registering, unzipping, initialization, and so on).
Described in this way, a Scriptlet is almost identical to ActiveX controls. It doesn't yet require special treatment such as registering or licensing, but it is often composed of several helper files, be they images, sounds, other Scriptlets or simply linked local pages.
However, what ultimately makes a Scriptlet require a packaging process is its innermost nature: a Scriptlet is a software component. In addition, a Scriptlet is HTML-based, and HTML documents are usually compound documents that host a variety of files in a number of formats.