Это называется устойчивой хорошей практикой, которая позволяет в будущем избежать большого кол-ва ошибок.

Для начала надо определится с терминологией:

cursor - Класс драйвера, через который происходит взаимодействие с базой данных.
connection - Класс подключения к базе данных.

У любой базы данных есть максимально допустимое кол-во подключений. Как и максимально допустимое кол-во открытых курсоров.

Если не закрывать - вы рано или поздно упретесь в лимит.

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

Так же нужно понимать что при создании подключения к базе данных у вас отжирается определенное кол-во оперативной памяти которое для этого необходимо. Если плодить много подключений - можно сожрать всю память.

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

Если вы не хотите постоянно закрывать подключение и курсоры - вы можете оформить код через конструкцию with. Тогда подключение и курсор будут закрывать автоматически, после выполнения блока кода в конструкции.

Как итог:

1) Закрытие позволяет избежать ошибок, связанных с использование одних подключений в разных потоках.
2) Не расстрачивает вашу оперативную память для создания ненужных подключений.
3) Не забивает базу ненужными подключениями.
4) Позволяет правильно распоряжаться транзакциями, и делать в определенной транзакции только определенные действия, а не пихать все в кучу.
5) Вы не упираетесь в лимит подключений и не получаете ненужных об этом ошибок.
6) Вы не получаете ошибок о том, что одно подключение пытается взаимодействовать с таблицей или данными, созданными в другом подключении, и залоченными или не расшаренными на данный момент.

Статья на эту тему о деплое Django проекта от компании-хостера Digital Ocean

Но если коротко говорить то nginx - это веб-сервер, который может обрабатывать HTTP-запросы и может отправлять его на сервер WSGI, и сервер WSGI обрабатывает приложение django.
У джанго есть встройка fastcgi, но тот же gunicorn как представитель WSGI-подобных серверов лучше потому что его родной
почитайте о маршрутизации запросов от клиента к серверу, и решите какие методы для вас лучше. Не обязательно использовать именно nginx.

Советую youtube канал Олега Молчанова, там есть замечательные уроки по Django, асинхронному программированию, системе контроля версий Git и методике ветвления Git-Flow, а так же все про тестирования и TDD. Для старта в программировании на python этого более чем достаточно. Сам лично учился по этим урокам.