Everything_is_not_so_bad

Kotlin как и все JVM-основанные языки имеет сложный рантайм. Который обладает способностью прогреваться от постоянных запусков. И поэтому чтобы точно и уверенно замерять перформанс - нужно правильно подходить к проблеме. Например использовать JMH для изммерений.

А для редких (одноразовых) запусков Python действительно может быть быстрее. Это я сам наблюдал в AWS-Lambda.
Функция лямбда которая вызывается 1 раз в сутки должна быть написана на чем-то вроде Python/NodeJS.

1. Нет, либо нет в 99.9999% случаев
2. Да, чтобы ограничить то, на скольких OS тредах может расположиться рантайм. Это прямо влияет на CPU-bound задачи и почти не влияет на IO-bound. Например, у тебя есть функция, которая перемножает матрицы. В канал поступают матрицы, есть 10 горутин, которые читают оттуда и умножают матрицы. Очевидно, что если GOMAXPROCS будет == 1, то все эти горутины будут жить на одном треде и будут "мешать" друг другу, задействуя не более одного ядра процессора. Если GOMAXPROCS будет 10, то каждая горутина может расположиться в отдельном ОС треде и считать себе там матрицы на "собственном" ядре.
3. Увеличится канал (sic!). Канал — это очередь. Канал без буфера — это "очередь", в которую можно добавить элемент только если с другой стороны этот канал кто-то пытается прочитать. Если такого нет — горутина будет ждать, пока этот канал кто-то захочет прочитать и наоборот, если кто-то читает канал, а с другого конца никто туда не пишет, то горутина будет ждать до тех пор, пока в канал кто-то не захочет записать. Если в канале есть буфер, то это уже становится полноценной очередью. Есть N слотов, если кто-то пришёл записать в канал, канал никем не слушается и там есть хотя бы один свободный слот — этот "кто-то" запишет в канал и пойдёт по своим делам и только если в буфере нет свободных слотов, то этот "кто-то" будет ждать, пока слот освободится. И наоборот, если кто-то слушает канал и в буфере канала уже что-то есть, то он сразу забирает первый на очереди элемент и уходит. Обычно это делают, чтобы сгладить нагрузку. Например, у тебя есть парсеры, которые что-то парсят, чтобы потом записать на диск. Но диск — штука непредсказуемая, может записать за 1мс, а может тупить 20мс. Довольно странно, если парсер будет ждать диск эти 20мс, хотя у него есть работа, которую он может выполнять прямо сейчас. Для этого можно создать буфер, куда парсер будет кидать данные СРАЗУ, а горутина, которая пишет на диск, заберёт их "когда-нибудь потом", когда диск перестанет тупить.

Как мне кажется вы не правильно ставите задачу. По сути менеджеры и разработчики решают разные задачи.
Поэтому для разработчиков phpmyadmin а для менеджеров как вы и сказали самописное приложение с возможность быстрого ввода карточек и несколькими отчетами.

Во-первых, while блокирует воркер так же, как и join. Во-вторых, Flask не предназначен для многопоточности и её в нём следует избегать. Лучше использовать асинхронность или очередь задач.

1) Если вы разработчик: Из макета-> У дизайнера
2) Если вы сам себе дизайнер:
Взять на бесплатных стоках фоток / сделать самому изображения / украсть на любом сайте
Google: photo stock free

stable diffusion?

Вам компилятор четко пишет

main redeclared in this block {строка 8 столбец 6 }
previous declaration at ./hello.go:18:6

Перевожу: функция main написана несколько раз, второй раз она встречается в файле hello.go на 18 строчке.
Видимо, у вас в одной папке несколько файлов и в нескольких из них есть функция main. Так делать нельзя, все, что находится в одной папке, го считает одним пакетом.

Что касается второй ошибки, отправляйтесь изучать основы синтаксиса языка, иначе далеко так не уедете. У вас лишние запятые в конце списка параметров и в конце списка переменных.