Vindicar

1. Не надо так делать. Сайту твоя долбёжка запросами не понравится. Как минимум, введи задержку от 10 минут и более.
2. Ты ознакомился с тем, как вообще работают асинхронные приложения? Судя по терминологии вроде "независимый while", нет. Почитай на эту тему, она не тривиальная, но без понимания основ асинхронщины ты далеко не уедешь.
3. Зависит от библиотеки, но так или иначе тебе нужна корутина, которая сначала делает запрос к сайту (лучше тоже асинхронно, с помощью aiohttp) и обновляет хранимые в кэше сведения, а потом спит нужный интервал времени (и не с помощью time.sleep()!). Эту корутину надо запустить в рабочем цикле (loop) asyncio, а потом уже запускать остального бота. Тогда боту практически всегда будет доступен этот кэш.

Передразнивая одного человека, асинхронность это кооперативная многозадачность плюс цикл обработки событий.

Упрощенно, есть набор функций, умеющих приостанавливать и возобновлять своё выполнение - корутин.
Корутины обычно приостанавливают своё выполнение после запроса операции ввода/вывода, но могут и по другим поводам - например, просто ожидание, или ожидание завершения другой корутины, или ещё что.

Ядром асинхронной программы является паттерн "реактор" - рабочий цикл. В контексте клиентского JS это рабочий цикл браузера, в контексте ноды - что-то отдельное, я полагаю (с нодой не работал).
Цикл делает следующее:
- ожидает завершения одной из операций ввода/вывода или ожидания (любой)
- определяет, какая корутина ожидала эту операцию
- передаёт ей управление
- корутина делает своё дело, обрабатывая результат операции
- потом корутина либо завершается, либо планирует еще одну операцию. И цикл возобновляется.

Отсюда и вытекают все плюсы и минусы. С одной стороны, переключение между корутинами происходит в явно указанные моменты времени, так что меньше возни с синхронизацией.
С другой стороны, длинные вычисления так не распараллелишь - только ввод/вывод. Ну или в длинном вычислении время от времени делать паузу, но выигрыша все равно не будет. Так что это имеет смысл только для IO-bound программ.

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

Ну если тебе нужна очередь, то asyncio.Queue в руки - или её эквивалент из threading, если решишь использовать потоки.
Асинхронность поможет только если обработка элементов содержит большую долю ввода/вывода.

Подозреваю, что дело в синхронном input(). Пока код стоит в нём, другие корутины не выполняются.
В прииинципе можешь схитрить и использовать run_in_executor().
Грубо говоря, он позволяет вынести длительный синхронный код в отдельный поток, и завернуть это в обычный task. Так что с точки зрения остальной програмы код становится как бы асинхронным.

EDIT: а ещё есть пакет aioconsole - как раз для таких вещей.

Как будешь параллелить выполнение CPU-bound задач?

Ты грузишь весь миллион адресов в память, дважды.
Первый раз, когда делаешь f.read(), потом в рамках .splitlines() создаётся копия (разбитая по кусочкам-строкам).
Ну и да, миллион индивидуальных тасков - это тоже дохрена. asyncio ведь надо проверить, может ли тот или иной таск продолжить работу.

Я бы сделал фиксированного размера пул тасков-воркеров , и заставил каждого воркера в цикле делать f.readline() самостоятельно, чтобы получить url для загрузки. И весь список в памяти хранить не надо, и контроль над количеством тасков получше.

По поводу ресурсов, мне очень понравилось объяснение тут (первая часть, ссылка на продолжение в конце текста):
https://krondo.com/in-which-we-begin-at-the-beginning/
На английском, но написано по-простому. Кроме того, автор пишет хоть и пространно, но зато последовательно показывает откуда вообще взялась концепция асинхронного программирования, в ответ на какие задачи оно было придумано, и как оно упрощает эти задачи. По сути, в ходе этой статьи мы изобретаем велосипед, чтобы потом понять как классно ездить на мотоцикле. =)