Scriptlets are based on the DHTML object model in the sense that they are capable of exploiting the features of this model. Nobody prevents you from writing scriptlets that do something else. Anything that can be packaged into a Web component could be packaged as a scriptlet, because the DHTML object model lends itself to being driven from external objects. Such objects might be WebBrowser-based executables (written using VisualBasic or C++) as well as other HTML pages.
Actually, the key point of scriptlets is not to let you drive the DHTML elements from another page. The point is to let developers provide an abstraction layer over some DHTML implementation.
Basically, the idea behind scriptlets is to abstract away DHTML functionality and expose a public interface for the component you are building with DHTML. So the final goal is to let you provide a self–contained component based on DHTML features. This component can then be automated in the usual object-oriented manner through its public interface made of properties and methods.
After all, DHTML is like a low-level but object-oriented Application Programming Interface (API) while scriptlets are software components built on top of it. This is a very important distinction and the heart of how scriptlets work.