намного упроститься задача распознавания капчи спам ботам

Я не совсем согласен. Каждый спам-бот расшифровывает капчу с какой-то вероятностью. Т.е. если он в принципе способен "пробить" каптчу, то с какого-то раза он это сделает. Задача для него усложниться только если новая картинка будет сгенерирована по новому алгоритму (другие шрифты, другой тип деформации и т.п.). Но даже крупные порталы редко такое делают.
Наверное эта вероятность немного снизится если показывать каждый раз другую картинку.
Но, на мой взгяд, гораздо эффективнее установить ограничение на количество запросов с одного IP.

использовать сесии Code Igniter которые хранятся на стороне клиента в зашифрованых кукисах

Тут у меня вопрос. У Вас есть сведения о том насколько сложно их расшифровать и выполнить подмену данных? Я знаю, что многие считают стандартные сессии CI уязвимыми и существует по крайней мере 7 альтернативных библиотек.

За счет чего Вы видите минимизацию нагрузки в таком случаи?

Не нужно генерировать картинку. Вопрос может составляться из готовых фрагментов текста, которые хранятся в обычном массиве.
А на счет сложности тут Вы, конечно, правы. Я встречал людей которые практически не умеют считать в уме. И чтобы решить пример типа 27-8 начинают искать калькулятор

Но мог бы быть и лучше

Тут я должен с Вами согласиться. Может стоит написать новый вариант этой статьи?

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

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

1)"Первый, сохранение файла действительно выглядит лишней операцией, но если посетитель ошибся при заполнении формы, можно отправить ему тотже файл, а не генерировать его заново."

Нет Вы не правы, так нельзя делать. Потому, что в таком случаи намного упроститься задача распознавания капчи спам ботам. Если при не правильном вводе, картинка и код не обновляются, можно написать скрипт который будет пытаться распознать изображение с разными настройками до тех пор пока ему это не удастся, ну или банальный полный перебор (хотя это я уже утрирую ).

2)Второй, PHP сессии по-умолчанию хранятся в файлах, но в принципе можно использовать любой вид хранилища, в т.ч. и БД.

Да по умолчанию в файлах. Но на нормальных серверах стоит МекКеш который позволяет хранить в оперативе. Я согласен ПХП сессии тоже не панацея и с ними надо быть поосторожней так как на ресурсах с большой нагрузкой тоже будут проблемы если уж очень активно и там где не нужно их использовать. Но все же это намного оптимальней чем БД. А если использовать сесии Code Igniter которые хранятся на стороне клиента в зашифрованых кукисах проблема вообще решается очень красиво.

3)Третий, удаление устаревших картинок и записей в БД не обязательно будет происходить по одной, т.к. удаляются все записи старше какого-то момента. К тому же эту операцию можно вынести в отдельный скрипт и запускать cron'ом.

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

Ну по поводу альтернатив капчи . Чем больше Вы будете усложнять логические примеры, тем больше людей не смогут зарегиться. Так как надо учитывать тот момент, что есть "люди-бараны" . Которые с капчей с трудом справляються. По поводу нагрузки на сервер не согласен. Совсем даже не уменьшит. За счет чего Вы видите минимизацию нагрузки в таком случаи?

P.S. Отчасти Вы правы. Учимся все на ошибках. Чужих и своих. Но тут вопрос насколько быстро учимся. Чем больше будет качественных материалов, тем быстрей будем учиться. Если новичку в каждой статье вбивать в голову, что оптимизация очень важный аспект при разработке, тем быстрей он это усвоит и будет пытаться применять это на практике. Пускай в своем пока виденьи далеком от идеала, но все же это уже, что то. Это уже похоже на какой то стиль. Не хочу Вас обидеть. Метериал написан Вами не плох. Но мог бы быть и лучше . Просто потом приходят на собеседование программеры, которые делают запросы в цыкле и вместо свято уверены, что инфу лучше хранить в текстовых файлах а не в БД .

Теперь по теме. В принципе вы правы. Сейчас я бы не стал делать такую captcha, хотя описанный здесь способ приведен в документации к этой библиотеке.
И хочу отметить, три момента. Первый, сохранение файла действительно выглядит лишней операцией, но если посетитель ошибся при заполнении формы, можно отправить ему тотже файл, а не генерировать его заново. А создание новой картинки тоже достаточно ресурсоемкая операция.
Второй, PHP сессии по-умолчанию хранятся в файлах, но в принципе можно использовать любой вид хранилища, в т.ч. и БД.
Третий, удаление устаревших картинок и записей в БД не обязательно будет происходить по одной, т.к. удаляются все записи старше какого-то момента. К тому же эту операцию можно вынести в отдельный скрипт и запускать cron'ом.

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

P.S. Стиль программирования формируется всю жизнь в том числе за счет своих и чужих ошибок

То есть 4 довольно тяжелые для сервера операции, которые включают в себя работу с БД и обращение к файловой системе и запись на ХДД.

Вместо этого сокращаем до 2:
Генерим картинку отдаем браузеру
Инициализируем сесию (не важно какую, в CI можно использовать как стандартные сесии пхп так и встроеные в CI)

Все, о удалении нам ничего знать больше не нужно ибо у же не наша забота.

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