microcoder

Python - востребованный в настоящее время язык во всём мире и перспективный - есть задел на будущее.
Поэтому не должно быть проблем с поиском работы на удалёнке.
Чего только стоит машинное обучение, которое в основном и имеет реализации на python.
Во фразе "учить 1с или Php или вообще податься в web" чувствуется боль и отчаяние человека, который вот-вот упадёт на дно.
Я, когда отдыхал на Ибице, познакомился со шкипером-математиком, который ходил на яхте по морям и окиянам и при этом кодил на Питоне прямо там, на яхте. А потом девчонкам показывал графики в виде фаллосов-ромашек... Романтика + технологии = крутотень нереальная

нет нет нет да нет да да да...

Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

В целом API лучше делать с помощью фреймворков, поскольку в них уже реализованы тривиальные моменты по безопасности, аутентификации и авторизации. Вы можете использовать микрофреймворки, например тот же Slim. Вы даже можете сгенерировать роутинг для него используя генератор от Swagger.

В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

Логичнее всего держать проект в моно-репозитарии, если он не будет большим. Если вы точно не знаете насколько большим он будет, то можно разбить проект на компоненты и использовать Composer для управления зависимостями (советую полность прочитать эту страницу от корки до корки).

По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
Он в целом применяется для всех приложений.

Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
Дерзайте!

Хранимая процедура имеет уже скомпилированный план запроса (в MS SQL, Sybase это точно так).
Теоретически, если запрос сложный, хранимая процедура будет быстрее на время, которое требуется оптимизатору чтобы построить план.
Но практически, на единичных запросах, видимой разницы не будет.

d = {
    1: 'Оплата',
    2: 'Возврат',
    3: 'Рекуррентное списание',
    4: 'Блокировка',
}

r['opcode'] = d[r['opcode']]

Вместо встроенного ОРМ в джанге еще бы и шаблонизатор поменять на Jinja2. Но тогда какой смысл в джанге? Flask с расширениями отличное решение. Что страшного в global request? Это сделано для удобства.