The article doesn't mention them but there are incremental only UUIDs (NEWSEQUENTIALID in TSQL) that solve that problem. Or you can prefix it with a timestamp.
The sequencing of those UUIDs resets every time Windows restarts. Given the frequency of OS and SQL Server updates that require reboots, that wasn't good enough for any of my workloads.
Agree. And if you have two clusters, they will start at different IDs. Which is why I would probably prefix them with a timestamp (if it is not a sensitive information). Say the number of seconds since 1-1-2000. Fits on 32 bits, that still leaves you with 96 bit of entropy for a UUID, which is plenty to guarantee uniqueness unless you are working at massive scale.
Don't they have the same problems the article dislikes about auto increment numbers?
I don't think so. They don't disclose information (other than the timestamp if you use one, but each ID is still random). You will not get collisions between tables either. And unless you operate on a massive scale, you are unlikely to get collisions between machines (and you can always xor the ID with the hash of the server name to further reduce the collision risk).
For anyone interested checkout UUID v1 which includes a timestamp.