Вместо надписей для интервалов лучше использовать поля ввода - вдруг нужно будет указать бОльшие интервалы? Не щелкать же счетчиком до тысячи. Ну это как тебе удобнее

При загрузке ini сканируются все секции, и в список попадает также содержимое всех секций. Для списка адресов это приемлемо, но если захочешь там хранить настройки - они тоже попадут в список и будут пинговаться
Стоит загружать адреса только из секции адресов.

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

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

Когда первый список стал не нужен - стоит очистить его. Не критично, но и не хорошо.

Непонятно, зачем все эти переносы из списка в список.

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

Дошел до сердца алгоритма - перебор адресов.
Твоя прога работает так: загружает второй список данными из первого, начинает по очереди удалять элементы из второго списка, попутно пингуя их.
Слишком много лишних операций. Используй массивы - и память не придется тусовать за зря.

Потенциальный косяк: Время опроса 3 секунды, таймаут пинга 100мс, список из 50 адресов, все в дауне. Что будет?

После определения ошибки, при неудаче пинга, происходит поиск в settings.ini количества принятых байт. Смысл?
Вероятно должен был искать имя по пингу? Так вот - ищет не имя, а количество байт. Смотри приоритеты данных в хэлпе.
Также этот шаг не очень оптимален. Зачем искать что-то на диске, если ты же уже загрузил имена в отдельный список.
Используй массивы. Грузи имена в один массив, а адреса в другой. Зная индекс адреса, моментально получишь имя.
Заметь - никакой лишней нагрузки на память, проц и диск, а значит больше ресурсов остается свободными для других косяков

При нормальной работе процедура обработки лога несколько раз в секунду загружает и выгружает один и тот же файл, если кто-нибудь в дауне. Можно было сделать и экономичнее.
Да и лог короткий - всего 100 строк. Значит он реально не используется, т.к. будет забит полностью за несколько циклов пинга, т.е. в пределах минуты.
Значит по этому логу не ведется какой-либо учет, и он используется только как способ узнать, кто из списка был в дауне на момент закрытия программы. Так?

Потенциальный косяк - бесконечный рост лога в памяти во время работы программы. Список строк лога все растет и растет, но не убывает.

После того, как лог был записан, и адрес был найден, происходит самоочистка первого списка.
Несколько непонятен этот шаг. Вероятно ошибка?
Если нет, тогда и логики нет: список проверки постепенно будет сокращаться, пока не станет пустым, и проверять будет нечего. Какая-же это циклическая проверка?
Одновременно здесь зарыт второй косяк: если кто-то упадет и поднимется, ты этого уже не увидишь, ведь его адрес навсегда исчезнет из списка проверки.

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

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