Frame::setTTL() and Frame::getTTL() appear to have been added to support some sort of selective update mechanism/frame cache, but these values are never used in current MediaWiki:
https://codesearch.wmcloud.org/search/?q=getTTL&files=&excludeFiles=&repos=
The only use is in ApiExpandTemplates where the TTL is reported as part of the API output.
Further, the documentation for Frame::getTTL() implies that it should apply up the frame tree: "Set the TTL of the output of this frame and all of its ancestors" but there is no code anywhere which walks the frame tree to compute the TTL in this way. Ie, in theory every Frame::getTTL() should return the minimum of its own local Frame::$ttl and the result of Frame::getTTL() on all child frames, but frames don't even maintain pointers to their child frames (frame pointers point up to the parent, not down to the children).
EDIT: PPTemplateFrame_Hash::setTTL() calls $this->parent->setTTL($ttl); which probably implements the needed frame tree walk, albeit somewhat inefficiently (parents walked even if no change to $ttl is made).
There is a lot of code which carefully computes accurate TTLs for functions involving dates and times, for example ParserFunctions::timeCommon() from Extension:ParserFunctions, the implementation of formatCurrentDate in Scribunto, and Language::sprintfDate in core, but this information appears to be complete unused. The only /effective/ date-related TTL adjustment seems to be in CoreMagicVariables in core, which handles __CURRENTMONTH__ and similar, and directly updates $parser->getOutput()->updateCacheExpiry().
The Frame::getTTL()/::setTTL() methods should probably be deprecated, and the code which uses it should instead change to updating the cache expiry in the ParserOutput, the way that CoreMagicVariables does. This will be compatible with Parsoid (which doesn't export a full Frame stack to clients) and selective update (which handles serializing and merging ParserOutput objects from fragments).