There are several intersecting issues relating to identity in ad tech today, and the challenge is that many times the solutions don't match directly with the most significant problems. The single most significant problem is that browsers are blocking third-party cookies. Safari has gone the furthest and makes it difficult to do any form of cross-domain tracking. Firefox is not far behind. Chrome, on the other hand, may never block third-party cookies and is roughly the size of all other browsers combined.
The discussions today around identity are often about solving the problem of syncing cookies across different ad tech providers. A number of the ID consortia, for example, create a single cookie that various ad tech partners can use without needing to sync each partner with each other. While this is helpful, the IDs often reside in a third-party domain and thus don't survive Safari and Firefox blocking. Alternatively, the IDs live on the publisher's first-party domain, meaning that they may provide session-level frequency caps on a particular publisher, and can be used for short-duration click-through attribution, they provide a small subset of the functionality available to cross-domain cookies.
Alternatively, many of the ID solutions require an email or similar identifier to be entered by the user and live on a first-party domain and then use a hash of the identifier to synchronize across domains. These may work on the set of publishers that can compel users to enter this information, but ultimately their ability to scale will be tied to users' willingness to submit their emails (or other ID - or the solution's ability to somehow scrape an identifier from the HTML) on each publisher, on each device, on each browser, around once a month. I'm not particularly optimistic about this approach, despite potentially increasing use of email walls and publishers beginning to share first-party domains (to expand the scope that the ID works for). Further, GDPR makes many attempts to force users into tracking potentially (probably) illegal. There is at least one identity solution that apparently makes use of unique identifiers generated by the operating system during the SSL/TLS handshake, and while this may survive cookie blocking, it's of dubious legality and, given Apple's overall stance on privacy, unlikely to survive once Apple catches on.
This is all to say that the set of publishers that will allow any form of persistent identity will continue to decrease. Non-Safari, non-Firefox, non-European users will be targetable, but the pool of users that can be cookied continues to shrink. But marketers have generally not changed their tactics, so the industry is trying to create solutions that persist or optimize the legacy sort of solutions. But really the problem is upstream — the old tactics will work less and less. They will continue to work for a while, albeit decreasingly, so the pressure to find new ones isn't intense yet. But really the industry needs to be thinking hard about the future of monetization. This means marketers should be thinking about the type of monetization that works well in a cookie-less world (probably more branding), and publishers need to be thinking about revenue diversification as well as monetization strategies that provide the sort of branding experiences that work in a cookie-less world.