Not to be mean but simply to warn anyone who may actually consider what you're suggesting, this is some of the worst, overly simplified, and most misinformed database advice I've read in 30 years of designing large and small relational data structures.
Thousands of organizations all over the world, including several I'm presently working to help to recover, have suffered needlessly for years from poor query performance because of this nonsense.
Even these days, integer-based primary and foreign keys wildly outperform string-based keys.
Depending on the particulars of the scenario, integer-based keys table joins perform up to twice as well as string-based keys.
Use integer (bigint) keys for performant table joins, indexing (good luck indexing and joining on UUID keys in a performant way), etc, and add a secondary UUID key to help with external data requests, data migrations, data archiving and restoring, etc. Hell, throw in a tertiary, human-readable, text-based key to make development and troubleshooting easier.
Where is it written that a table can have only one unique key value?
The scenarios you point out are all valid, but the solution you propose makes a lot of bad assumptions, e.g. why would a properly designed authorization layer EVER let an unauthorized user access data simply because s/he guessed an integer key value?
In the UUID counter-example you provide, literally the only differences are the sequential nature of integer-based counters and the size of the number space, which is essentially "security through obscurity".
Please, please, please, I beseech you, stop teaching the young 'uns that the earth is flat. Some of 'em are bound to believe you, and the unnecessary suffering will continue into yet another generation.
