I read it (and regret it is a waste of my time). Their arguments are:
* integer keys are faster;
* uuidv7 keys are faster;
* if you want obfuscated keys, using integer and do some your own obfuscation (!!!).
I can get on-board of uuidv7 (with the trade-off, of course, on stronger guessability). The integer keys argument is strange. At that point, you need to come up with a custom-built system to avoid id collision in a distribution system and tries to achieve only 2x saving (the absolute minimal you should do is 64-bit keys). Very puzzling suggestion and to me very wrong.
Note that in this entire article, the recommendation is not about using natural keys (email address, some composite of user identification etc.), so I am skipping that whole discussion.
> (with the trade-off, of course, on stronger guessability).
you're not guessing 2^72 bit random number. And if guessing UUID does something in your app, you already fucked up
You can hand out chunks of sequential ids from a central coordinator to avoid collision; this is a well-established pattern.
Re: natural keys (or something like it), I was using it as an example of how badly PK choice can impact performance at scale.