Помимо случаев, когда вам нужно использовать чужой API, который требует UUID, конечно, всегда есть другое решение. Но решат ли эти альтернативы все проблемы, которые делают UUID? В конечном итоге вы добавите больше слоев хаков, каждый для решения своей задачи, когда вы могли бы решить все их сразу?
Да, для UUID теоретически возможно столкновение. Как отметили другие, это невероятно маловероятно до такой степени, что это просто не стоит рассматривать. Это никогда не случалось до настоящего времени и, скорее всего, никогда не случится. Забудь об этом.
Самый «очевидный» способ избежать коллизий - позволить одному серверу генерировать уникальные идентификаторы для каждой вставки, что, очевидно, создает серьезные проблемы с производительностью и вообще не решает проблему автономной генерации. К сожалению.
Другое «очевидное» решение - это центральный орган, который заранее раздает блоки с уникальными номерами, что, по сути, и делает UUID V1, используя MAC-адрес генерирующей машины (через OUI IEEE). Но дублирующие MAC-адреса действительно случаются, потому что каждый центральный орган в конечном итоге облажается, поэтому на практике это гораздо более вероятно, чем коллизия UUID V4. К сожалению.
Лучший аргумент против использования UUID состоит в том, что они «слишком большие», но (значительно) меньшая схема неизбежно не сможет решить наиболее интересные проблемы; Размер UUID является неотъемлемым побочным эффектом их полезности при решении этих самых проблем.
Возможно, ваша проблема недостаточно велика, чтобы нуждаться в том, что предлагают UUID, и в этом случае не стесняйтесь использовать что-то другое. Но если ваша проблема неожиданно обостряется (а большинство так и делают), вы в конечном итоге переключитесь позже - и пните себя за то, что не использовали их в первую очередь. Зачем проектировать на провал, когда так же легко проектировать на успех?