four4

Почитайте историю SQL
Изначально он создан для НЕ ДЛЯ ПРОГРАММИСТОВ.
Сложно писать идеальные, быстро выполняющиеся запросы.
А просто на рядовом уровне знать SQL способен не программист, а менеджер, для них SQL и был создан

Файловая система вообще то не бесконечно вложенная может быть....
Довольно небольшое число вложений каталогов допускается.

Ты объясни заказчику, что можно сделать и бесконечно, но работать будет медленее, чем оптимизированное под конкретное количество категорий. Может, он тут же одумается. И заложит с запасом на будущее, например, 20 уровней

Он о посетителях сайта, кстати, подумал? Как они будут продираться сковь эти все вложенности? Объясни ему - тут же станет более конкретным.

А технически бесконечная вложенность реализуется элементарно:

Хотя это и не лучшая модель для хранения данных в реляционных БД
каждая строчка в таблице БД это отдельная категория.
она содержит ссылку (идентификатор, первичный ключ) категории более высокого уровня.
К сожалению, чтобы добраться до всех этих категорий - придется множество запросов делать к БД, а это зело медленно. Чем глубже вложенность - тем медленнее будет работать.

Можно подумать и оптимизировать, но, имхо, овчинка выделки не стоит.
Проще привести заказчику 2 довода (см. выше) - и он тут же станет очень конкретным и можно более оптимальную структуру БД создать.

Я вам, конечно, отвечу то, что вы не хотите услышать и не получю зеленую галочку на ответе, но нет никакой разницы.
То есть абсолютно.

Какой есть (хороший, разумеется) программист под рукой, какую технологию он знает/предпочитает - на том и писать.

Качество конечного продукта от языка программирования не зависит, а зависит от того, кто будет реализовывать, от его квалификации.

• Устойчивость - это что еще за параметр, по крайней мере не общеупотребимый термин?
  
• Читаемость кода - это вообще смешно, зависит от того кто пишет.
  
• Скорость выполнения - значение этого фактора преувеличивают новички или люди, которые не являются специалистами, гораздо важнее как именно спроектировано и написано, а не от языка - можно запросто затормозить и быстрый язык и быстро работающую систему реализовать на медленном языке.
  

Если вы заказчик - то не занимайтесь не свойственными вам вопросами, пусть решает исполнитель.
Если вы исполнитель - то писать нужно на том, что лучше знаешь.

Если она изначально не multi-tenancy, то никак.
Если бы была спроектирована под mutli-tenancy - просто в каждой таблице дополнительное поле и фильтровать ВСЕГДА по нему, чтобы не видеть чужих данных. Но чтобы сейчас, на готовой уже системе, так сделать - это глубоко лопатить код с риском, что увидят чужие данные, если вы ошибетесь.