Тут Вам по кусочкам дали ответ, осталось собрать воедино, чтобы было понятно что к чему. Далее по пунктам:
1) Первое и самое главное здесь то, для чего вообще это хеширование нужно. Правильный ответ Вам дали "олды", о которых Вы сами упомянули, +
Сергей Горностаев привел пример отличной книги, где об этом можно почитать подробнее. Если в двух словах, то в распределенных базах данных(когда они хранятся в более чем одном экземпляре) прежде чем сохранить какую-то информацию в какой-то из экземпляров нужно для начала понять, а в какой именно экземпляр должны сохраняться определенные данные. Вот представьте, Вы регистрируетесь в инстаграм, там сотни экземпляров баз данных, как им определить в какой вас сохранить? И тут как раз вступает в дело та самая хеш-функция по каким-то уникальным данным(например по мэйлу или по номеру телефона), которая дает на выходе число. Именно это число определяет в какой экземпляр базы данных сохранить конкретного пользователя(чаще всего там используют деление по модулю на количество экземпляров, ну об этом подробнее можете прочитать в книге, о которой говорилось).
2) Теперь о том, почему это используют как id вместо обычных чисел. Причин может быть на самом деле много, я вам приведу сейчас самую наглядную, а подробнее уже сами потом изучите. Как говорилось выше, распределенная база данных это множество разных экземпляров баз данных, где в каждом экземпляре свои данные. Вот представьте, что у нас 10 разных экземпляров. И хеш-функция по вашему логину указала, что вас нужно сохранить в экземпляр №6. А по моему логину хеш-функция показала, что меня нужно сохранить в экземпляр №3. Тогда что получается: и я и вы теперь записаны в таблицу Users, только ваша таблица Users не имеет никакого отношения к моей, потому что эти таблицы находятся в разных базах данных. То есть логически это одна база данных, но по факту это разные экземпляры. И если бы мы с вами были первыми пользователями и в качестве id использовались бы обычные числа(например автоинкрементные поля), то в базу данных записалось бы два пользователя с одинаковым id(если мы первые пользователи то оба получили бы id=1 каждый в своей базе), что является катастрофой. Так вот чтобы избегать подобных ситуаций, используются специальные идентификаторы, которые называются
uuid. Все популярные СУБД имеют встроенную поддержку таких идентификаторов и способы их генерации. Однако насколько я понял в вашем случае вместо использования встроенных функций для генерации uuid разработчики используют результат хеш-функции в качестве этого самого uuid, что довольно классное решение на мой взгляд. А что касается производительности - результат этой хеш-функции это такое число в шестнадцатиричном виде(только чуть больше, 20 байт против 16 у uuid), как классический uuid, поэтому производительность вряд ли пострадает.