сарказм -- это акцент любого взрослого мужика;

абсолютной нужности/ненужности не существует -- оно всегда определяется конкретным случаем;
если в сях или ассемблере нет многого нужного, значит там оно не нужно;
а те вещи, где оно есть, были созданы именно чтобы оно там было;
потому что в других местах его либо не было, либо было, но с нюансами (вроде лицензий или наличия оператора goto, например);

void* часто используется просто потому, что нельзя заранее, на этапе проектирования, точно предположить все возможные варианты данных, которые придётся передавать в функцию;

const void* -- это информирование вроде "эта функция вот эту переменную менять не будет, мамой клянусь", причём при подключении .so или .dll такое определение -- единственная возможность сообщить компилятору, что переданную функции переменную можно считать неизменяющейся;  в действительности функции передаётся адрес, и как конкретно она будет его использовать -- зависит только от неё, проконтролировать это нельзя никак.

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

"типо-безопасность" относится сюда же: программист должен либо понимать, что конкретно он напроектировал, либо читать документацию к тому, что напроектировал кто-то другой (или читать исходники, если доков не получилось, а поделие использовать приходится;  но это сильно ненадёжно, особенно если поделие продолжает развиваться кем-то другим).

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

если ограничения оказываются проблемой (как в случаях системного ПО, например), язык приходится выбирать низкоуровневый, который обычно был C;

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