If you consider the evolution of scripting over the last few months, you'll notice a kind of continuity that makes the next step appear perfectly natural, given all the previous ones. This evolution began with the advent of DHTML. DHTML highlighted the need for a more powerful development platform to increase the level of code reusability. This need is the very origin of scriptlets, or to be more precise, DHTML Scriptlets.
Such components are nothing more than Web pages with a special layer of script code that shapes a public interface through methods and properties. Most of these features are accomplished through Javascript's built-in functions. In addition, you need a kind of external engine to host scriptlets in both HTML pages and Visual Basic forms.
The next step is a generalization of this external engine which transforms it into a run-time module capable of providing a full-fledged COM interface to the external callers. In this way, DHTML Scriptlets become a special case of Server Scriptlets. In other words, Server Scriptlets are a superset of the functionality of the existing scriptlets. This will be particularly evident when we take a look at the source code of Server Scriptlets and make a comparison with DHTML Scriptlets.
So to answer the original question—why Server Scriptlets? It is mainly because they are the next step in the evolutionary process. Server Scriptlets encompass DHTML Scriptlets and provide the same functionality through a more general and powerful interface.