The AMP tracker doesn’t quite have the same features as the JS tracker, because it’s an extension of the AMP project, and therefore is restricted to how that platform works and what it will allow a third party extension to do.
It doesn’t, for example, offer as stable a means of setting cookies, nor does it offer a means of generating a globally unique UUID. What it does offer is a unique user identifier in the AMP client ID.
Because of these quirks of how tracking in AMP works, the user identification strategy is different - we don’t expect a domain userid, because the platform doesn’t offer a means of replicating the function of the domain userid (similarly to how it doesn’t quite make sense to expect on when tracking in a mobile app).
v2 of the AMP tracker will attach an ‘AMP ID’ context to each event. It will contain the AMP client ID, the userid (if it’s set) and, if the user has navigated from a JS-tracked page which has the cross-domain-linker enabled, it will contain the domain userid for the previous page too. For journeys passing from AMP pages to JS-tracked pages, the AMP cross-domain linker will pass the AMP ID across, so it can be parsed from the querystring and decoded.
There’s some documentation on this here: https://github.com/snowplow/snowplow/wiki/Google-AMP-Tracker-v2#43-user-identification.
TL;DR: The amp client ID is ostensibly what you would use instead of a domain_userid, and the AMP ID context should offer you a mechanism to stitch user identity across platforms in data modeling - the strategy here is to match domain userids to AMP client IDs.
Hope that’s helpful!