Absolutely use Pega's out-of-the-box Data Classes. Your Data Types should be encouraged to inherit from - or be composed of - Data Classes that are provided by Pega Platform. For example:

• The webinar made reference to classes in the PegaData-* series (PegaData-Contact, PegaData-Address, etc);
• Page Lists of classes from the SingleValue-* series (e.g. SingleValue-Text, SingleValue-Integer) are a Data-Transform- and UI-friendly alternative to Value Lists. 
• Clipboard instances of Embed-NameValuePair are useful for recording one or more name/value pairs as the outcome of executing a rule.

Reuse Pega-provided properties via inheritance or composition where you can assure that no other Pega behavior results in those properties being set. For example, setting .pyStatusWork to record the outcome of a process step is unwise, as the Pega engine may overwrite this with a work item status from other configuration of the case type or internal engine processing. 

Defining a Client-specific Address class which extends PegaData-Address should totally reuse the City property to store the City of the Address. That's one of the reasons you've elected to extend it.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.