The two main reasons for implementing a handler to work with your local server are speed and document portability. First, an object handler can generally satisfy most of the requests a container might make of an object, such as drawing an object on a specific device or making a copy of the object in another IStorage. Object handlers might also be capable of reloading a linked file and providing an updated presentation to the container. An object handler generally does not have the capability of activating objects itself, especially where editing and user interface are concerned. A handler might be capable of playing a sound, for example, but it might not be capable of providing the user interface to manipulate the sound. Therefore, the handler has much less code than might be present in a local server because most of the code in such a server usually exists for editing. Imagine how small a word processor would be if all it had to do was read and display text but never edit it. That's the idea of a handler. The speed advantage comes from the fact that the handler is a small DLL optimized to perform specific actions, such as drawing and rendering presentations. Because it's a DLL, it is loaded much faster into a container's process than an EXE could be launched, and there are no cross-process calls to be made for most operations.
Portability is a little less tangible. To explain what I mean by portability, let me use the following scenario: A user on one machine has created an embedded object of class X using the local server for class X, and the user has saved that object in a container's file. In this case, let's say that besides the object's native data, the file also contains a cached screen presentation and a cached presentation for a PostScript printer.
Now let's say this document is sent to other users who do not have the local server for class X on their machines because they have no use for editing the object, only for viewing and for printing it. Because the container's file has cached presentations for this object, these users can open those files and view or print the object. However, this assumes that the cached presentations are compatible with the output devices these users want to send them to. If they have only 16-color displays and the cached presentation uses 256 colors, the screen display might be ugly. If their printer is only dot matrix, the only possible presentation to send to such a printer is the one for the screen because we know that sending PostScript data to a dot-matrix printer gets us nowhere. In either case, the output quality is poor.
There are two solutions to this. First, you could sell these secondary users copies of the local server, but why would they want to pay for extra copies merely to print? You wouldn't want to let them freely copy your server either. So that solution won't work. A different solution is much better. You can provide an object handler that can render a presentation for an object's data reasonably well on any display or printer and allow your customers to freely distribute this handler. Not only does this result in optimal output quality, but it allows the container not to cache any presentations at all if it wants, making the compound document file much smaller. Because the handler is simply a small piece of code that can only display and print objects, people do not need a full application for those purposes. You can allow users to copy this file, and they can put it on a floppy disk along with a document so that the recipient of the document has the tools necessary for optimized output. This is a big advantage for you and your customers—objects always show up nicely regardless of where they're created and where they're displayed. Such is document portability.
The bottom line with both benefits is that object handlers improve object performance and can be confidently licensed for free distribution to optimize output wherever the object happens to travel. Because a handler does not include editing capabilities (which would qualify it for luxury tax), people still have an incentive to purchase your full server.
Just as an aside, you could have a handler display some advertising whenever a user attempted to use a feature that requires the full server. For example, a handler typically passes IOleObject::DoVerb to the default handler, which would try to launch the local server. If that fails, the handler can display a message that says, "Because you'd really like to edit this object, why don't you call our toll-free number right now and have your credit card handy so that we can get this product into your hands by tomorrow morning for the incredibly low price of $149.95?"