Ну можно тупо в тригере 5 вейтов в 3 сек поставить, после каждого - востановить здоровье triggering unit.

Он и после пятого и 105ого не потеряется

как грамотно решать такие задачи:

1) Создаем виртуальный класс-свойство объектов HealingItemTypeAlpha01.
2) Определяем действия которые данное свойство может и будет выполнять, тупо пишем на это действие исчерпывающую функцию и связываем её с названием.
2.2) У нас все завязано на событие, событие в нашем случае - время, вы должны конкретно указать время, подробнее ниже


3) Каждый юнит должен иметь некоторое свойство, делающее этот юнит уникальным именно для нас, это тупо порядковый номер регистрации.

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

5) Наша система должна оперировать юнитами, тестзапуск происходит в момент инициализации системы и при добавлении-удалении любого юнита из системы, но не чаще чем 0.03125 секунды, это 32 фрейма в секунду, то есть максимум 32 запуска в секунду.

6) В момент проверки система проверяет юнитов состояние которых изменилось с прошлого запуска, для этого мы ведем дополнительные списки, если юнит создан, мы пишем его кроме прочего в batchlist ровно как удаленных юнитов.

7) Система запускается 32 раза в секунду все равно, но смотрит только батчлист, если он пуст то таймер пропускает итерацию.
7.2) Метод может иметь альтернативу, так называемый variabletimeframe когда система анализирует действия и запускает таймер на нужное число фреймов, но тут возникают сложности в управлении, так как если появились новые задания, их потребуется обработать отдельно, отложив одно задание и выполнив другое, а потом продолжить.
Это у нас стек с сортировкой действий по времени исполнения.
У нас есть 100500 заданий, которые пишутся в хронологическом порядке и исполнение идет от одного задания к другому.

8) В batchlist е после повешания этого самого бафа мы обнаружим ID юнита, проверив ID юнита мы обнаружим в списке эффектов HealingItemTypeAlpha01_INIT_TIMESTAMP что предписывает каждые 3 секунды производить предписанные в отношении юнита действия.

9) Следующая итерация которая предписывает действия произойдет через 96 вызовов и потом каждые 96 вызовов.
9.2) Соответственно мы добавляем к итерации таймера проверку на прохождение нужного промежутка времени или пишем в сортированный стек действия в том порядке, в котором они будут исполнены.


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

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

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