Ole Agesen
in his
dissertation

The Dylan language  illustrates the tension between the desire to maximize expressiveness and the need for concrete type information to address pragmatic concerns such as execution efficiency and application size when delivering applications.

The design goal for Dylan was to provide the programmer with a flexible dynamic language (hence, “Dylan”) for “rapid creation, delivery, and subsequent modifications of (…) software.” Yet, to satisfy the additional goals of being “practical on small machines” and “achieve commercial performance in production code,” the designers of Dylan introduced concepts that allow the programmer to significantly limit the polymorphism of code, sealed classes being the most important example. A sealed class cannot be subclassed. Consequently, the class type of a sealed class is a concrete type consisting of a single exact class: the sealed class itself. Moreover, any method operating on a sealed class is monomorphic. Concrete type information was gained, but at cost in flexibility: sealed classes cannot be subclassed, and code operating on their instances is monomorphic.

Thus, the designers of Dylan accepted giving up some flexibility to improve deliverability.