Ключевое слово — API :)

Пусть rails-приложение будет, к примеру, сервером и по оговоренному адресу ожидать входящих данных. А php-приложение вместо того, чтобы слать email, шлёт HTTP-запрос на сервер rails.

Правильно ли я понимаю что для хранение файлов их нужно разбивать по папкам,

Неправильно.
Для того, чтобы файлы загружались и благополучно отдавались, сегментировать (разбивать по папкам) их совсем не обязательно.

Проблемы, про которые Вы могли слышать, связаны лишь с получением полного списка файлов в директории. Да, это долго и тормознуто, но никак не влияет на скорость чтения конкретного файла.

А на боевых серверах использование хранилища в локальной файловой системе и вовсе нонсенс. Там эта проблема не стоит в принципе.

Сегментацию можно сделать для, скажем так, красоты. Или чтобы было понятно, кому принадлежит тот или иной файл. Но практическая польза от неё сомнительна. Вреда, впрочем, тоже нет :)

допустим на сервер пользователь с Ником username заливает файл file.mp4, и я сохраняю этот файл по пути u/us/use/user/usern/file.mp4 и такой путь формируется для каждого пользователя

Опять неправильно.

Во-первых, никогда, НИКОГДА не доверяйте данным, пришедшим от пользователя. Сохраняете загруженный файл – сгенерируйте имя сами. А оригинальное имя не возбраняется сохранить и в другом месте. Если понадобится дать возможность пользователю сохранить файл под оригинальным именем, это делается в несколько строк.

Во-вторых, Ваша сегментация слишком агрессивная. Если представить, что юзернейм может состоять только из строчных латинских букв и цифр (итого алфавит 26+10=36 символов), то такое хранилище сможет вместить 36 ^ (1 + 2 + 3 + 4 + 5) = 36^15 = 2.21 * 10^23 файлов без повторений. А что если юзернейм короче 5 символов? А что если он переименуется?

Помните "во-первых"? Так как нам нужно самим придумать имя файла, почему бы не воспользоваться либо UUID и сгенерировать уникальное (с высокой достоверностью) значение вида 28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc, а его уже сегментировать? Например, два сегмента по два символа датут прикольные ссылки вида 28/c5/28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc и возможность разместить 65 тысяч файлов так, чтобы они были по одной штуке в директории :)

Есть также вариант использовать не UUID, а посчитать контрольную сумму файла и взять её в качестве имени. Практическая ценность такого хеша, правда, тоже стремится к нулю :)

если будет 2 одинаковых названия файла у одного пользователя то просто добавляю к новому файлу номер (file1.mp4)

Если речь идёт о Джанге, то она сама так делает, это штатная функция хранилища.

Вы вот тут про REST пишите, а имеете в виду, вероятно, django-rest-framework (лучшее, на мой взгляд, существущее решение для организации RESTful API для джанги).

Для начала ответьте себе на вопрос: а нужен ли вообще API Вашему сайту. Если объективно нужен (например, с сайтом взаимодействует мобильное приложение, причём не только читает данные, но и отправляет; или фронтэнд построен таким образом, что от сервера требуются только данные, а отрисовка HTML происходит на клиенте; или Вы предоставляете информацию "неживым" пользователям — роботам), то RESTful API хороший выбор. И DRF, соответственно, тоже.

Если всего этого нет и Вас вполне устраивает схема, когда бэкенд генерирует весь HTML и отдаёт его клиенту, то DRF, REST, да и вообще API в целом не нужны.

А зачем, чтобы когда база утечёт, злоумышленник смог легко расшифровать базу? Пароли должны криптоваться необратимо. А под восстановлением пароля обычно понимают создание нового. А старый уходит в историю