It is required that the OPC Foundation specifies rules, an algorithm and some concrete sample values for the KeyLifetime limits (min and max) for its communication type OPC UA PubSub /Part 14/ with AES-CTR.
E.g.:
Rule 1.) a key MUST be updated latest before the SequenceNumber of the MessageNonce reaches the 4 Byte SequenceNumber value limit of 2^32.
and Rule 2.) a key SHOULD be changed the earlier the better. This additional 'SHOULD' rule depends on a risk management i.e. the acceptable attack success probability. For an attack success probability of e.g. 2^60 maximum 0,3887 TB encrypted payload are allowed for one key (from https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, chapter 1.2). Before this data limit exceeds the key should be updated.
-> An algorithm from rules 1.) and 2.) should result depending on SequenceNumber limit, PublishingInterval and encrypted payload with concrete sample KeyLifetime limit values to be specified in the OPC Foundation for PubSub /Part 14/.

But consider: it is not assumed that the referenced recommendation for TLSv1.3 with AES-GCM can be used for OPC UA PubSub /Part 14/ because PubSub uses AES-CTR and is also a different communication type than TLS: PubSub with fast multiple network messages in a worst case with several messages with the same key and the same process data values which increases key attack success probability.
In consequence the OPC Foundation should specify an own recommendation and algorithm for KeyLifetime boundaries for its communication type PubSub.

See also Meeting Minutes from Foundation Subgroup PubSub Prototyping, TOP 1: https://opcfoundation.sharepoint.com/:w:/r/UA/work/@Sub-Groups/PubSub%20Prototyping/Meetings/2021/2021-05-10/UA%20PubSub%20Telecon%20minutes%202021-05-10.docx?d=wcdf47da1ea0e4c3fa4e783355742a3ec&csf=1&web=1&e=AbPw1S