Стас, вот откуда у тебя такие познания если ты работаешь без году неделю и ничего кроме поделок, которые отдали на откуп бодишопу, не видел? У идентификаторов, которые генерятся при помощи последовательности есть один существенный недостаток (и он не звучит как "Стас не одобряет"), а именно: "из коробки" такие идентификаторы нельзя переносить из одной базы в другую, т.е. флоу вида: тут чет консультанты поделали в тестовой БД, чего-то поназаводили, давайте то что они сделали перетащим в прод, работает так себе, но эта проблема с легкостью решается путем подмешивания информации о среде в сам идентификатор (просто берем и старшие биты резервируем под идентификатор системы), даже более того, в идентификатор можно подмешивать тип сущности и получить возможность обращаться к сущностям из вне без указания типа сущности, и при этом "число" останется "числом", а с ууидами ты такое уже не провернешь. Кроме этого с рандомными PK существуют проблемы в базах (в особенности в которых принято кластеризовывать данные в таблицах на основе PK: MSSQL и InnoDB, насколько мне известно) - в каких-то случаях это хорошо (нет горячих блоков в индексе и таблице), а в каких-то наоборот плохо - на больших вставках нужно много IO (вот здесь заливка батчами реально всосет если РК - это uuid).

это какбы самая передовая технология:
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2570145300346198113 a GUID should be a 16 byte raw (hopefully they are not using a 32 byte varchar2..) and will perform adequately as a primary key.