Ideally a specialization of a capability delivered from a Pega class is driven by a justifiable, Client-specific need to vary the existing behavior. For example, the PegaData-Address.PostalCode property references an Edit Validate rule that checks the pattern entered for a Postal Code.
The pattern enforced out-of-the-box may not be suitable in the Client's region, in which case the existing rule would be specialized to reference a different Edit Validate, or perhaps none at all.
A client-specific subclass MyOrg-Data-Address which direct-inherits from PegaData-Address allows the PostalCode property to be class-specialized in a way that allows applications that need this alternative PostalCode behavior. Those applications define Address properties that reference MyOrg-Data-Address as their data type. Should the Pega-provided behavior in PegaData-Address be needed by other applications for the same client, those applications can continue to engage it by referencing PegaData-Address for the data type of their Address properties.
This approach is more upgrade-friendly too, for should future improvements be provided to the PegaData-Address.PostalCode formats...
These improvements shall be honored by the client applications that referenced PegaData-Address for their Address data; whilst
Those client applications that referenced MyOrg-Data-Address - consciously overriding the Pega implementation with something client-specific - continue to realize the specialized behavior at runtime.
Inevitably there will be situations where Ruleset-specialization is the only practical method of specialization available. Maintain an inventory in your project documentation of Pega-provided rules that have been masked by Ruleset-specialization, as these should be reviewed specifically when upgrading Pega.