Actually, you will generally get the best performance using int/bigint as your primary key. Non-sequential ids, like UUIDs, can lead to index fragmentation which slows down joins and queries.

Be aware that it's not an either/or choice. You can use ints as primary keys, but also use UUIDs as public keys to overcome the issues with exposing your primary keys mentioned in the article.

Also ... just don't store UUIDs as strings; the performance will be awful. Many databases have a uuid type. Postgresql has uuid, SQL Server has uniqueidentifier.

UUIDs as primary keys do have uses, for example, as mentioned in the article, if you have multiple databases that need to be occasionally synced, UUIDs are useful to prevent key collisions. I have databases that run on ships (i.e. disconnected from the internet for long periods) and they periodically need to be synced via replication to databases on shore. UUIDs are super handy in this case.